Changes to pfctl to allow easier integration into a library

[Christian Mauderer]

Am 09.08.2016 um 21:42 schrieb Adrian Chadd:
> [snip]
> 
> hi,
> 
> I'm looking at this, because I'm thinking of what it'd take to make
> some of this stuff in a daemon and be persistent, versus having to
> fork/exec commands in a memory constrained environment.
> 
> Some static vars are effectively consts and are consts. Those may just
> be committed as-is to make things clearer.
> 
> Some are actual state, which means I can't run this in a
> multi-threaded environment.. :)
> 
> 
> 
> -adrian
> 

Hello Adrian,

I'm quite sure there would be some more use cases where a library would
be preferable to a stand alone tool. This could also simplify calls from
perl or python scripts. Like I already mentioned in my first mail
Sebastian had a discussion into this direction in 2013:


https://lists.freebsd.org/pipermail/freebsd-hackers/2013-October/043553.html

If it is of any use to you, you can take a look at the method we use here:

  https://git.rtems.org/rtems-libbsd/

Please note that this work is currently based on an FreeBSD 9.3. Some of
the changes (mainly in the user space tools) make it hard to update to
the current version. I hoped that my approach that I used on pfctl would
bring us closer to the FreeBSD sources. Some of the other tools (like
route which has been ported as one of the earlier tools) have some
extensive modifications. We plan to reduce the modifications in the future.

Most of the tools use a mutex to prevent parallel execution of multiple
instances of the tool. But it could be really tricky to have multiple
instances of a configuration tool like pfctl (or ifconfig, or ...) at
the same time anyway. So this is not really a restriction.

Kind regards

Christian
-- 
--------------------------------------------
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.