Date: Wed, 15 Apr 2015 14:53:34 +0200 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Gleb Smirnoff <glebius@freebsd.org> Cc: "freebsd-net@freebsd.org" <net@freebsd.org> Subject: Re: moving ALTQ out of contrib Message-ID: <CA%2BhQ2%2BhLm9FvNJhnZrz4BytN1%2BTig=brgi07ZK7TUS9KKym82w@mail.gmail.com> In-Reply-To: <20150415122627.GZ883@glebius.int.ru> References: <20150414135346.GU883@FreeBSD.org> <20150415073823.GA94402@onelab2.iet.unipi.it> <20150415122627.GZ883@glebius.int.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 15, 2015 at 2:26 PM, Gleb Smirnoff <glebius@freebsd.org> wrote: > On Wed, Apr 15, 2015 at 09:38:23AM +0200, Luigi Rizzo wrote: > L> > With the new ifnet KPI, that is now being developed in projects/ifnet, > L> > the ALTQ will need some tweaking. It is discontinued by initial author > L> > for a decade now, and it has already experienced direct commits in > L> > our tree. Thus, I see no good reasons to continue keeping it in contrib. > L> > In NetBSD they have it in sys/altq. > L> > > L> > I'd prefer to move it to sys/net/altq. > L> > > L> > Any objections or better ideas? > L> > L> my first question is what is the expected residual lifetime of altq ? > > If I get it working properly in projects/ifnet, I see no reasons to > remove it. It is going to be a plugin into network stack and will no > longer require editing drivers. It will run on drivers that aren't > supported by ALTQ now. However in the latter case the ALTQ will sit > on top of interface own queue, and will start to work only when > interface's own queue overflows. But if we later add a new interface > method to modify length of own queue at runtime, this issue will > go away. > > L> If it is destined to be removed soon (and probably that is not > L> unlikely given its unmaintained state, the absence of multiqueue > L> support etc.) maybe we could live for the next > L> couple of years just leaving it where it is now and avoid the > L> repo churn. > L> > L> If we really plan to relocate the code, I guess the options are > L> > L> sys/altq as in netbsd > L> > L> sys/netaltq this would be an alternative location to > L> the above one, justified by the fact that > L> we have already a bunch of net* subdirs > L> > L> sys/net/altq as you propose, i guess to stay close to > L> the rest of the ifnet code (and perhaps > L> as a first step in cleaning up sys/net > L> by putting stuff in various subdirs) > L> > L> In any case my preference would really be to leave it where it is. > > I don't like to keep in contrib a code maintained and edited by the > project. Especially I don't like tautological path of contrib/altq/altq. > I don't like extra glue in Makefiles, especially modyfing CFLAGS for the > whole kernel build. > > If it is a regular piece of kernel code, let it be like the rest of > kernel code. ok thanks for the clarification. Then if you do sys/net/altq/ do you also plan to split the current content of sys/net/ into separate subdirectories ? We currently have quite a few separate things in sys/net/, such as - various bpf files - generic ifnet support (including raw sockets) - various libraries (compression and hash functions) - routing code - bridging code - a ton of special ifnets, (tun, tap, epair, gif, ....) - bridging code that could benefit from a bit of partitioning cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BhQ2%2BhLm9FvNJhnZrz4BytN1%2BTig=brgi07ZK7TUS9KKym82w>