Date: Fri, 29 Jul 2016 09:31:49 +0200 From: Christian Mauderer <christian.mauderer@embedded-brains.de> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Changes to pfctl to allow easier integration into a library Message-ID: <fd9b3e22-01ef-93f2-5792-520307e49c0a@embedded-brains.de> In-Reply-To: <B2EA8BF5-115F-48D0-9561-68D3AE4642CD@lists.zabbadoz.net> References: <25df9fd5-be75-b9ae-aa3a-22abef3bddf0@embedded-brains.de> <B2EA8BF5-115F-48D0-9561-68D3AE4642CD@lists.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 28.07.2016 um 17:59 schrieb Bjoern A. Zeeb: > On 28 Jul 2016, at 14:03, Christian Mauderer wrote: >=20 >> 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): >> > =E2=80=A6 >> Would the attached patches be acceptable for integration into the >> FreeBSD sources? >=20 > Hi, >=20 > (a) I=E2=80=99d prefer uintX_t to u_intX_t and I think FreeBSD is using= the > former generally. >=20 > (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. >=20 > Would you be willing to look into this? >=20 > 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 --=20 -------------------------------------------- embedded brains GmbH Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.mauderer@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=C3=A4ftliche Mitteilung im Sinne des EHUG= .
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fd9b3e22-01ef-93f2-5792-520307e49c0a>