Date: Fri, 7 Sep 2012 10:02:47 +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: <CAPBZQG1iQ31bxMkKOKUUFpfOt15YMxgx1hmnj3HsQSj%2B%2BGJYqw@mail.gmail.com> In-Reply-To: <20120906064640.GL15915@glebius.int.ru> References: <20120905115140.GF15915@FreeBSD.org> <50476187.8000303@gibfest.dk> <20120905183607.GI15915@glebius.int.ru> <CAPBZQG0a4WVB4W4OwF3CAJH-G4DTDan-Nz1HR1SFAgFOfe%2Ba=Q@mail.gmail.com> <20120906064640.GL15915@glebius.int.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 6, 2012 at 8:46 AM, Gleb Smirnoff <glebius@freebsd.org> wrote: > Ermal, > > On Wed, Sep 05, 2012 at 10:02:17PM +0200, Ermal Lu?i wrote: > E> as already shared with you the opinion the new 're-arrangement' of > E> data structure together with new syntax > E> is more helpful to SMP in general, so complementary to this work. > E> As the person who has done most of the work on last import of pf form > E> OpenBSD, so you > E> can say knowledgeable about the internals of it, will still recommend > E> the new syntax. > E> - No more multiple rulesets is the single biggest reason. > > The new or old syntax is completely orthogonal to SMP. The SMP scalability > is all about the storage, not about rulesets. > > I have looked into newer OpenBSD and their new pf modifies rulesets from > the forwarding path more then pf-4.5 did, thus it is not "more helpful > to SMP in general", but the opposite. > > E> > Bulk imports are no longer possible (unless one wants to ruin all my work). > E> > We have had some pain with bulk imports. The last one, for example, have > E> > broken pfsync completely. > E> > > E> > First, imports were made with focus on minimizing diff to OpenBSD. Code was > E> > made compilable on FreeBSD and somehow working. But the operating systems have > E> > diverged very much sincle last 15 years, and thus quality porting requires more > E> > than just make it compile. For example, OpenBSD runs network stack under splnet(9). > E> > They can run ip_output() anywhere in the network stack (except of ip_output() > E> > itself, heh). We can't since that would make lock order reversals. This was just > E> > one example, but believe me, there are much more. All this peculiarity were worked > E> > out correctly in my branch. So, this branch is not about SMP scalability only, > E> > this is a better port of pf to FreeBSD. > E> > > E> > E> This is more a issue of FreeBSD rather than OpenBSD perse. > E> pf(4) has survived with code sharing so far quite well and i have seen > E> nothing in your project branch that does a better job to this. > > I'd prefer not survival for the pf, but robustness and performance :) > > Let me number the most important things in my project branch that do better job: > > - safely decoupled stack when sending generated packets: pf_send_tcp(), pf_send_icmp() > - safely decoupled stack when sending pfsync(4) deferrals > - safely removed the "pfugidhack" > - provided correct locking in pf_route(), pf_route6() > - offloaded the "flush" functionality to a taskqueue > - removed unsafe lock dropping before malloc(9), or unsafe entering malloc(M_WAITOK) > with locks held > - removed unsafe lock dropping before copyin(9)/copyout(9) > > E> > Second, the imported code (what we have now in head) is polluted with zillions of > E> > ifdefs and is difficultly readable even by the person who wrote it. Any other > E> > developer runs away in fear when he faces that. This ends up with no one willing > E> > to fix open problem reports. We have now 53 PR assigned to freebsd-pf@. They are > E> > rotting and no one takes them. Most of these PRs can't be forwarded to OpenBSD, > E> > since they are specific to our port (yep, port has problems - see above paragraph). > E> > > E> This is not an argument but just whining. > E> Too much code in FreeBSD has that. > > "Too much code in FreeBSD has that" isn't an excuse either an argument. > > E> > >From my point of view the state of pf in FreeBSD is (was) a dead end. We don't > E> > modify it, since it isn't ours, but we hope that new bulk import would fix problems. > E> > > E> > I hope that new state of pf in FreeBSD would attract more developers to it. I > E> > have nothing against with cherry-picking new features from OpenBSD (but > E> > taking into account new multithreaded design). I have nothing against completely > E> > new features. I'd appreciate any attempt to reduce number of PRs assigned to > E> > freebsd-pf@. > E> > > E> > T> Currently the common "pf-ecosystem" that we've always more-or-less > E> > T> shared with OpenBSD seems to be crumbling. If we are going to continue > E> > T> along our own "branch" of pf, with old syntax and SMP support, and who > E> > T> knows what else in the future, should we consider renaming it to avoid > E> > T> having two similar-but-not-identical firewalls with the same name ? > E> > > E> > May be it is worth renaming, I have nothing against this. But I don't > E> > think it is already time to rename right now. Now the only rewritten part > E> > is keys/states storage, all other code is shared with OpenBSD, however > E> > touched a lot. > E> > E> I would suggest this, and always would be for this, > E> since too much expected internal behavior has changed internally with > E> what i have seen on your project branch. > E> > E> People can test the renamed version and have an option to roll back to > E> the previous one. > E> After all you are saying that its not pf yourself. > > I won't keep OpenBSD-pf and FreeBSD-pf in parallel in FreeBSD. The OpenBSD-pf > port have proved to be poorly maintained. After last import that was made > by you, at least the following regressions were introduced: > > - enabling pfsync immediately panics > - kldunload pf.ko immediately panics > Going to personal attacks shows your willing to discuss as civilized person. Though that does not mean anything in the sense that bugs are there to be found by testers. If you have not found out yet, testers for something that people take for granted as firewalls are scarce in general. Something that has been learnt from history is that people want software X to be compatible with software Y from where it came from. They are not interested on X to use the same rules but hey its different from Y because of Z. > Hey, these aren't a difficult to catch bugs, that require special setup > or weeks of catching a race condition. This is basic functionality, and panics > are evidence that code wasn't tested properly. Okay, we all ain't saints, and > people do errors. But why wasn't you promptly fixing these errors? You just > dropped many Kb of code into SVN (via bz@) and then disappeared. Have you closed > at least on PR in GNATS? > AFAIK i fixed any reported panics on freebsd-pf list. I did not even go the PR route because i had other plans which $DAYLIFE/WORK still have not allowed to pursue. Furthermore, there is nothing guaranteeing that you will not do the same, or have the same bugs in different fashion, i.e. VIMAGE/VNET?!. Just because you are doing work right now and are the only one behind these changes, AFAIK, does not mean its a long term partnership or that you will provide better SLA on this part. As a last comment on this: Keeping your patched pf, which is still contrib software btw, under a new name for one RELEASE cycle makes sure that nothing breaks during this period. You and I will never be able to run all the tests needed for such critical subsystem because cannot have all those environments in one place. This is just to avoid having to deal with critcal bugs as you have pointed before just after a RELEASE. > If you (or anyone else) really loves vanilla pf from OpenBSD, and if for you > word "new" implies "better" then you should just install OpenBSD and enjoy > the newest pf available in the world. > There is only one reply to this but i will spare in public list, sorry. -- Ermal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPBZQG1iQ31bxMkKOKUUFpfOt15YMxgx1hmnj3HsQSj%2B%2BGJYqw>