Changes to pfctl to allow easier integration into a library

[Christian Mauderer]

Am 28.07.2016 um 17:59 schrieb Bjoern A. Zeeb:
> On 28 Jul 2016, at 14:03, Christian Mauderer wrote:
> 
>> Hello,
>>
>> I'm currently working on a porting pfctl to a real-time operating
>> system. This is done using the same framework that Sebastian Huber
>> mentioned here (and probably at some other occasions):
>>
> …
>> Would the attached patches be acceptable for integration into the
>> FreeBSD sources?
> 
> Hi,
> 
> (a) I’d prefer uintX_t to u_intX_t and I think FreeBSD is using the
> former generally.
> 
> (b) All the variables you pulled out of functions that are not const,
> would need to be virtualised for VIMAGE, as otherwise one virtual
> network stack could affect another.
> 
> Would you be willing to look into this?
> 
> Gruesse
> /bz

Hello Bjoern,

thanks for the feedback.

Regarding (a): Normally I would prefer the POSIX names from stdint.h
too. But it seems that the whole pfctl code uses the u_intX_t names.
Therefore I used this naming convention too. I think if the type names
are changed, this should be done in one commit for the whole pfctl code.
Should I create such a patch?

Regarding (b): Of course I can look into it. I only have the problem
that I didn't know VIMAGE before you mentioned it. I took a quick glance
at the following page:

  https://wiki.freebsd.org/VIMAGE/porting-to-vimage

It seems to me that this is meant for kernel code only and not for a
user space application like pfctl. Did I miss something? Is the pfctl
code used directly in the kernel somewhere? Or is the virtualisation
also necessary for user space tools?

Please don't understand me wrong: I have no problem doing the work. On
contrary: As far as I can tell, the macro wrappers that are used in
files like sys/netinet/igmp.c could be useful for our porting effort
too. It seems that they wrap exactly the variables that are problematic
for us. So it would be at least simpler to identify the problematic
variables. It's even possible that we could use the macros to manipulate
the variables in the way we need.

Kind regards

Christian Mauderer
-- 
--------------------------------------------
embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.