Date: Wed, 15 Apr 2015 15:26:27 +0300 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: net@freebsd.org Subject: Re: moving ALTQ out of contrib Message-ID: <20150415122627.GZ883@glebius.int.ru> In-Reply-To: <20150415073823.GA94402@onelab2.iet.unipi.it> References: <20150414135346.GU883@FreeBSD.org> <20150415073823.GA94402@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150415122627.GZ883>