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