Date: Wed, 14 Mar 2007 12:57:26 +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: <20070314095725.GA1766@comp.chem.msu.su> In-Reply-To: <20070313004543.A54774@xorpc.icir.org> References: <20070310153534.GA35834@comp.chem.msu.su> <20070313004543.A54774@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 13, 2007 at 12:45:43AM -0700, Luigi Rizzo wrote: > On Sat, Mar 10, 2007 at 06:35:34PM +0300, Yar Tikhiy wrote: > > Hi folks, > > > > Just noticed that neither ipfw(8) nor /etc/rc.d/ipfw cares to load > > dummynet.ko. It can result in a broken setup when one migrates > > from a custom monolithic kernel to GENERIC with modules, which is > > a nice way to reduce support headache today. > > > > There are at least two possible ways to deal with the issue. The > > easy way is to give the task of loading dummynet.ko to /etc/rc.d/ipfw. > > The problem with it is that the script cannot know in advance if > > dummynet is really used by the ipfw rules to be loaded. The decision > > whether to load the module is left to rc.conf(5) in this case. > > i think this is a reasonable option and the one to use for all ipfw > extensions (divert, dummynet, in-kernel nat and so on). Thank you for your reply! Loading dummynet via rc.d is really easy, I think I can add it. However, I'm afraid it won't be a real long-term solution -- please see below. > 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 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 divert. Or the inner function do_cmd() can load a missing module before issuing setsockopt(), which is even better as we won't load the module on a read access or if the command line contains a syntax error. do_cmd() can even load ipfw.ko itself so that people no longer have to type, e.g.: (kldload ipfw && ipfw add 65000 allow ip from any to any) > /dev/null 2>&1 insead of just: ipfw add 65000 allow ip from any to any if a need to load ipfw.ko for some experiments arise. > > The second way is to move the task of loading modules to ipfw(8). > > Then it could load ipfw.ko, divert.ko, and dummynet.ko on demand. > > cheers > luigi -- Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070314095725.GA1766>