merging projects/pf into FreeBSD head
reddit / BSD

----------------------------------------------------------------------
[deleted] · 2012-09-06 17:56

[deleted]

----------------------------------------------------------------------
Zebba_Odirnapal · 2012-09-06 20:10

Here's hoping freebsd-pf and the original keep sharing.

For more context on what's brewing with FreeBSD's version of PF, read
the **freebsd-pf** mailing list, too.

Message from Gleb, after announcing SMP PF ~~breaking~~merging into
head:

>On Wed, Sep 05, 2012 at 04:28:23PM +0200, Thomas Steen Rasmussen
wrote:
>T> Your work seems very exciting from a performance standpoint, and
it
>T> is certainty something I am looking forward to. Please don't take
the
>T> following as a critique of your important work :)
>T>
>T> In your orignal announcement you confirmed my fears that this work
>T> will make our pf divert a lot from OpenBSDs pf, making bulk code-
imports
>T> impossible in the future. As you know we are stuck on the old pf-
syntax,
>T> how will we ever get to the new pf-syntax if your work goes into
HEAD ?
>
>What's bad with "getting stuck" with old syntax? I personally don't
have
>any problems with it. I have had problems with performance, however.
>
>Here you are advocating to a thesis that new => good, older => bad.
If
>we believe this thesis, and focus on keeping up to date with OpenBSD,
>then we will spend zillions of manhours porting newer and newer and
>newer pf to FreeBSD, but we will always get the old one, because
OpenBSD
>will be at least one minor revision ahead of us. This race can never
>be won. Samba will never become Windows :)
>
>However, if someone eagers to see new syntax in FreeBSD, I have
nothing
>against this. Just sit down and port it. Yes, porting will require
some
>time to understand code and quality port it to FreeBSD.
>
>Bulk imports are no longer possible (unless one wants to ruin all my
work).
>We have had some pain with bulk imports. The last one, for example,
have
>broken pfsync completely.
>
>First, imports were made with focus on minimizing diff to OpenBSD.
Code was
>made compilable on FreeBSD and somehow working. But the operating
systems have
>diverged very much sincle last 15 years, and thus quality porting
requires more
>than just make it compile. For example, OpenBSD runs network stack
under splnet(9).
>They can run ip_output() anywhere in the network stack (except of
ip_output()
>itself, heh). We can't since that would make lock order reversals.
This was just
>one example, but believe me, there are much more. All this
peculiarity were worked
>out correctly in my branch.  So, this branch is not about SMP
scalability only,
>this is a better port of pf to FreeBSD.
>
>Second, the imported code (what we have now in head) is polluted with
zillions of
>ifdefs and is difficultly readable even by the person who wrote it.
Any other
>developer runs away in fear when he faces that. This ends up with no
one willing
>to fix open problem reports. We have now 53 PR assigned to freebsd-
pf@. They are
>rotting and no one takes them. Most of these PRs can't be forwarded
to OpenBSD,
>since they are specific to our port (yep, port has problems - see
above paragraph).
>
>>From my point of view the state of pf in FreeBSD is (was) a dead
end. We don't
>modify it, since it isn't ours, but we hope that new bulk import
would fix problems.
>
>I hope that new state of pf in FreeBSD would attract more developers
to it. I
>have nothing against with cherry-picking new features from OpenBSD
(but
>taking into account new multithreaded design). I have nothing against
completely
>new features. I'd appreciate any attempt to reduce number of PRs
assigned to
>freebsd-pf@.
>
>T> Currently the common "pf-ecosystem" that we've always more-or-less
>T> shared with OpenBSD seems to be crumbling. If we are going to
continue
>T> along our own "branch" of pf, with old syntax and SMP support, and
who
>T> knows what else in the future, should we consider renaming it to
avoid
>T> having two similar-but-not-identical firewalls with the same name
?
>
>May be it is worth renaming, I have nothing against this. But I don't
>think it is already time to rename right now. Now the only rewritten
part
>is keys/states storage, all other code is shared with OpenBSD,
however
>touched a lot.

----------------------------------------------------------------------
Zebba_Odirnapal · 2012-09-07 19:49

> Second, the imported code (what we have now in head) is polluted
with zillions of ifdefs

Was just re-reading this and thought to myself "hey maybe NetBSD would
be interested..."