Who is to load dummynet.ko?

[Luigi Rizzo]

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.

	cheers
	luigi