Date: Thu, 13 Sep 2012 19:41:05 +0200 From: Luigi Rizzo <rizzo@iet.unipi.it> To: "Bjoern A. Zeeb" <bz@FreeBSD.org> Cc: luigi@FreeBSD.org, Gleb Smirnoff <glebius@FreeBSD.org>, net@FreeBSD.org Subject: Re: moving pfil consumers to sys/netpfil Message-ID: <20120913174105.GA22571@onelab2.iet.unipi.it> In-Reply-To: <alpine.BSF.2.00.1209131623350.13080@ai.fobar.qr> References: <20120912123457.GC85604@glebius.int.ru> <20120912211726.GB10974@onelab2.iet.unipi.it> <alpine.BSF.2.00.1209131623350.13080@ai.fobar.qr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 13, 2012 at 04:36:10PM +0000, Bjoern A. Zeeb wrote: > On Wed, 12 Sep 2012, Luigi Rizzo wrote: > > >On Wed, Sep 12, 2012 at 04:34:57PM +0400, Gleb Smirnoff wrote: > >> Hi, > >> > >> we (me and Bjoern) would like to establish a single place > >>for all kinds of pfil(9) consumers, for current ones and > >>for future as well. > >> > >> The place chosen is sys/netpfil. > >> > >> On first round we'd like to move there our Tier-1 firewalls: > >>ipfw and pf. This also includes moving pf out of contrib. > >> > >> The plan of movement is the following: > >> > >>sys/contrib/pf/net/*.c -> sys/netpfil/pf/ > >>sys/contrib/pf/net/*.h -> sys/net/ [1] > >>contrib/pf/pfctl/*.c -> sbin/pfctl > >>contrib/pf/pfctl/*.h -> sbin/pfctl > >>contrib/pf/pfctl/pfctl.8 -> sbin/pfctl > >>contrib/pf/pfctl/*.4 -> share/man/man4 > >>contrib/pf/pfctl/*.5 -> share/man/man5 > >> > >>sys/netinet/ipfw -> sys/netpfil/ipfw > > > >I have two concerns against moving ipfw/ > > > >- what do we gain by moving ipfw/ further > > away from its user header files (whose location in netinet/ > > is pretty much part of the API so difficult to change) ? > > What do we gain by having 3 firewalls ... in three different places > ... in the tree? The point of my question was that if you do some work you expect some return, in the short or in the long term, otherwise you are wasting time. If you leave things as they are at least you break even. (i don't know what is the third firewall you mention, but it is irrelevent). Specifically, for ipfw i think the move is a mistake for the reason i am explaining below. > The result is that ipfw unconditionally depends on a pf header file > .. oops .. that actually is an ALTQ thing *bummer*. > > > >- pfil is just one of the APIs that the ipfw code > > uses to send/receive packets (pfil, netmap for FreeBSD, > > and then netfilter and ndispacket for the other OS). > > The other two really don't count for us. > > > > The pfil dependencies amount to probably 1% of the code. > > So if we really want to relocate ipfw/ i'd rather move to > > a more generic place (but as far as i know we do not have > > one for subsystems -- dev/ is used for drivers, other stuff > > has generally accumulated under sys/ ,see geom, ofed, netgraph). > > You may remember we talked about this in the FreeBSD 8.0-CURRENT(?) > times when ipfw moved the last time. > > So suggestions as saying no and not coming up with anything better > is not helpful otherwise I'll tell to glebius "sorry for holding you > up for 3 days" go head with his initial proposal to also put pf into > netinet/pf if you'd prefer that? First of all: the relocation of pf/ is unrelated to the relocation of other subsystems. If Gleb or you or both feel that pf goes under netpfil/pf/ i am perfectly fine with it and i never said anything that blocks this move. Second: What i contest is the fact that you classify ipfw as a "pfil client", when pfil is just a tiny adaptation layer to access ipfw. I mentioned the three alternative APIs (netmap, netfilter, ndis) to witness the fact that pfil is irrelevant to ipfw's operation. Third: any code relocation comes with some pain -- specifically, netinet/ is hardwired in many #include paths in the ipfw sources > grep netinet/ipfw sys/netinet/ipfw/* | grep include | wc 35 70 1791 so having it relocated (and in different places between HEAD and STABLE/9, and other platforms that may not count for you but do count for the maintainer, aka me) causes some extra maintainance work which I am willing to take if there are good reasons, but i do not see now. So for pf do whatever you see fit, i never objected. For ipfw, i think that netinet/ is more appropriate than netpfil/ (i'd be ok with something like net-subsystems/ but we do not have one such a thing and i do not have the time and energy to discuss and create one). > /bz > > -- > Bjoern A. Zeeb You have to have visions! > Sometimes you wonder why people are so reluctant to cleaning things up > and finding a good soultion for the next decade. It's no fun probably? Is this coming from a new targeted .sig service ? :) Cleaning up/refactoring is actually quite fun and gives you the feeling that you get things done even though it is mostly mechanical work. It is the "finding a good solution" part that is much harder. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120913174105.GA22571>