From owner-freebsd-hackers@freebsd.org Fri Jul 29 07:31:55 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9FC90BA76DF for ; Fri, 29 Jul 2016 07:31:55 +0000 (UTC) (envelope-from christian.mauderer@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C2101BFC for ; Fri, 29 Jul 2016 07:31:55 +0000 (UTC) (envelope-from christian.mauderer@embedded-brains.de) Received: from [88.198.220.131] (helo=sslproxy02.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1bT2Gu-0004YH-88; Fri, 29 Jul 2016 09:31:52 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy02.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bT2Gt-0004t8-T4; Fri, 29 Jul 2016 09:31:52 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id CD93E2A1807; Fri, 29 Jul 2016 09:32:00 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id wcLaQW6QAwwr; Fri, 29 Jul 2016 09:32:00 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 536322A180B; Fri, 29 Jul 2016 09:32:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ikIC7FLfqwyZ; Fri, 29 Jul 2016 09:32:00 +0200 (CEST) Received: from mauderer-linux.eb.localhost (unknown [10.10.171.6]) by mail.embedded-brains.de (Postfix) with ESMTPSA id E844C2A1807; Fri, 29 Jul 2016 09:31:59 +0200 (CEST) Subject: Re: Changes to pfctl to allow easier integration into a library To: "Bjoern A. Zeeb" References: <25df9fd5-be75-b9ae-aa3a-22abef3bddf0@embedded-brains.de> Cc: "freebsd-hackers@freebsd.org" From: Christian Mauderer Message-ID: Date: Fri, 29 Jul 2016 09:31:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.99.2/21989/Fri Jul 29 08:57:54 2016) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 07:31:55 -0000 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= .