Date: Tue, 13 Mar 2007 00:45:43 -0700 From: Luigi Rizzo <rizzo@icir.org> To: Yar Tikhiy <yar@comp.chem.msu.su> Cc: freebsd-net@freebsd.org Subject: Re: Who is to load dummynet.ko? Message-ID: <20070313004543.A54774@xorpc.icir.org> In-Reply-To: <20070310153534.GA35834@comp.chem.msu.su>; from yar@comp.chem.msu.su on Sat, Mar 10, 2007 at 06:35:34PM %2B0300 References: <20070310153534.GA35834@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
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). 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. > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070313004543.A54774>