Replying to the top of the thread, but the text is actually
reply to those people in the thread, who eager for import of
new pf from OpenBSD.

  So, I claim that there is a vast and silent majority of people
who simply use pf and do not want the hassle with broken pf.conf.
I also claim that there is number of people who utilize pf at
larger installations and they were very glad to see pf to scale
on multiple CPUs and at least not to freeze the entire traffic for
seconds during expiry run.
  And you claim that there is another large number of people, who
want to run newest pf from OpenBSD on FreeBSD, and they do not
care about syntax change problems.
  Unfortunately, we cannot compare our large numbers. Well, you
can tell that your number is at least four times bigger than mine,
but you will not provide details on how can we check that. :)

  What can we do in this situation?

  Thanks to the pfil(9) framework, we can have as much firewalls
as we want. You can import new pf keeping the current version
intact. There could be some minor problems on decision how to
manage two different pfctls, and other utilities, but these are

  Let me restate. The FreeBSD version of pf IS NOT on your way
of putting OpenBSD version of pf to FreeBSD. What IS your main
obstacle in this task is the porting process itself. Try it.
Fork FreeBSD in git, mercurial, or simply checkout subversion
working directory, then:

# cd sys/netpfil
# mkdir openbsd-pf
# cd openbsd-pf

And start working. When you got a buildable and working version[*],
post call for testing email to current@ and pf@. After several
rounds of testing you will end up with something working. And
if we see that the demand for second pf in FreeBSD is real,
and you are willing to take maintainership of it, you will be
welcome as committer and second pf will be welcome to the tree[**].

Any takers?


[*] Spoiler: usually by that time both FreeBSD tree and pf
taken from OpenBSD would diverge and you would need to sync up :)

[**] This is my personal opinion, not an official project statement,
neither a core team member statement. I expect that there would be
resistance against yet-another-packet-filter, that you would need
to deal with. But if you got a working code, and you got a userbase
of the code, then you have chances to overcome the resistance. And
please don't start bikeshedding right now with no code at hand.

Totus tuus, Glebius.
_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to