Date: Wed, 14 Mar 2007 17:11:43 +0300 From: Yar Tikhiy <yar@comp.chem.msu.su> To: Luigi Rizzo <rizzo@icir.org> Cc: freebsd-net@freebsd.org Subject: Re: Who is to load dummynet.ko? Message-ID: <20070314141142.GB3830@comp.chem.msu.su> In-Reply-To: <20070314043506.A76618@xorpc.icir.org> References: <20070310153534.GA35834@comp.chem.msu.su> <20070313004543.A54774@xorpc.icir.org> <20070314095725.GA1766@comp.chem.msu.su> <20070314043506.A76618@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 14, 2007 at 04:35:06AM -0700, Luigi Rizzo wrote: > On Wed, Mar 14, 2007 at 12:57:26PM +0300, Yar Tikhiy wrote: > > On Tue, Mar 13, 2007 at 12:45:43AM -0700, Luigi Rizzo wrote: > ... > > > Making the load on demand would require a bit of additional code because > > > it depends on the actual rules being loaded, and the rules are not > > > parsed at load time. Plus, i believe that in a case like this > > > the decision of which modules to load should be a conscious one > > > taken upfront by the system administrator (i.e. end up in rc.conf > > > or loader.conf) rather than be the result of the actual ipfw > > > configuration. > > > > Well, I used to stick to this opinion, too, in the good old days. > > But today we are growing more and more modularity in our kernel, > > and it's a nice feature to have. With a lot of modules, the issue > > of double configuration appears: if I want feature FOO, I have to > > yes this is also try. > > > add its configuration AND not forget to load the respective module. > > It can be a pain as the number of such cases rockets up. Today at > > least mount, ifconfig, and netgraph provide for loading modules on > > demand, with the former two being system's core components. > > > > I've just taken a look at the ipfw userland utility code. It notices > > a "pipe" or "queue" keyword in its command line rather early, and > > it can be a good moment to check and load dummynet.ko. Ditto for > > actually, i think it is the kernel itself (in the setsockopt handler, > once it validates the rule) that should load the module, and not leave > the task to the userland utility. Other modules already do this, > e.g. iwi loads the firmware autonomously, and maybe even netgraph components > do something similar. > > For dummynet and divert, this can be surely put in the setsockopt > handler which is in ipfw.ko - if you need to autoload ipfw.ko, > then i am not sure where to put the hooks (in the kernel) but i am > pretty confident that there must be a good place. As our fortune file puts it, "If God is dead, who will save the Queen?" :-) We seem to have a sort of a chicken and egg problem here. Perhaps that's why most auto-loading is done from the userland. Of course, putting it in the kernel is better because it allows for different control tools unconcerned with the modules (imagining xipfw(8) here), but it has this shortcoming. Another funny point is that now it's impossible to unload a module auto-loaded by the kernel itself. I'm uncertain if it's an architectural limitation or "just in case". -- Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070314141142.GB3830>