Date: Wed, 5 Sep 2012 22:36:07 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Thomas Steen Rasmussen <thomas@gibfest.dk> Cc: pf@FreeBSD.org Subject: Re: [HEADS UP] merging projects/pf into head Message-ID: <20120905183607.GI15915@glebius.int.ru> In-Reply-To: <50476187.8000303@gibfest.dk> References: <20120905115140.GF15915@FreeBSD.org> <50476187.8000303@gibfest.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Thomas, 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. -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120905183607.GI15915>