Date: Wed, 5 Sep 2012 22:02:17 +0200 From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= <eri@freebsd.org> To: Gleb Smirnoff <glebius@freebsd.org> Cc: pf@freebsd.org Subject: Re: [HEADS UP] merging projects/pf into head Message-ID: <CAPBZQG0a4WVB4W4OwF3CAJH-G4DTDan-Nz1HR1SFAgFOfe%2Ba=Q@mail.gmail.com> In-Reply-To: <20120905183607.GI15915@glebius.int.ru> References: <20120905115140.GF15915@FreeBSD.org> <50476187.8000303@gibfest.dk> <20120905183607.GI15915@glebius.int.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Gleb, On Wed, Sep 5, 2012 at 8:36 PM, Gleb Smirnoff <glebius@freebsd.org> wrote: > 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. > as already shared with you the opinion the new 're-arrangement' of data structure together with new syntax is more helpful to SMP in general, so complementary to this work. As the person who has done most of the work on last import of pf form OpenBSD, so you can say knowledgeable about the internals of it, will still recommend the new syntax. - No more multiple rulesets is the single biggest reason. But you did not listen than i do not expect you to listen now. I do not even expect you to change your standpoint after your work. > 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. > This is more a issue of FreeBSD rather than OpenBSD perse. pf(4) has survived with code sharing so far quite well and i have seen nothing in your project branch that does a better job to this. > 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). > This is not an argument but just whining. Too much code in FreeBSD has that. > >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. > I would suggest this, and always would be for this, since too much expected internal behavior has changed internally with what i have seen on your project branch. People can test the renamed version and have an option to roll back to the previous one. After all you are saying that its not pf yourself. > -- > Totus tuus, Glebius. > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" -- Ermal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPBZQG0a4WVB4W4OwF3CAJH-G4DTDan-Nz1HR1SFAgFOfe%2Ba=Q>