Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Apr 2007 05:10:54 +0200
From:      Marko Zec <zec@icir.org>
To:        Julian Elischer <julian@elischer.org>
Cc:        Perforce Change Reviews <perforce@freebsd.org>, Marko Zec <zec@freebsd.org>
Subject:   Re: PERFORCE change 118226 for review
Message-ID:  <200704180510.54729.zec@icir.org>
In-Reply-To: <4623EC51.4080407@elischer.org>
References:  <200704161051.l3GApuxA044256@repoman.freebsd.org> <4623EC51.4080407@elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 16 April 2007 23:36, Julian Elischer wrote:
> Marko Zec wrote:
> > 	- pf can now be kldloaded, but is not virtualized (yet)
>
> I was thinking that the following might be an interesting
> way to think about  modules..
>
> kldloading a module is 2 parts..
> 1/ loading it in to memeory
> 2/ linking it in
>
> In the base vimage you do both, but in the others,
> then you only can link in modules that are already loaded.
>
> i.e.  each vimage is responsible for linking the modules that it
> needs (?)
>
> loading a new module to memeory doesn't mean that the functionality
> is automatically available for all existing vimages...
>
> child images do not inherrit all the linked modules of the parent..
> they need to link in those they need.

Yup this looks neat but could become an implementation nightmare.

For example in case of pf, to some "stack" instances we would have to 
expose the /dev/pf entry, while to those others that haven't been 
"locally-kldloaded" we shouldn't.

Or consider the sysctl interface in say ipfw - we would have to 
implement additional logic for hiding the sysctl nodes to those stack 
instances that haven't "loaded" the ipfw module.

But most importantly this would complicate traversing over stack 
instances in those code chunks that need to traverse through all 
stacks, many timers for example.  Those would now need to maintain 
separate per-module lists of active (loaded) and inactive instances - a 
nightmare of its own.

And finally we would have to take extra care about dependencies.  I.e. 
which modules must be unconditionally loaded in all stacks (like INET 
and INET6), and which can be left unattached until later explicitly 
requested by the instance owner.  

But I see the drive for this, both in terms of conserving system 
resources, and in preventing shoot-in-the-foot scenarios, like 
kldloading ipfw and then instantly breaking IP communication in all 
existing stack instances if ipfw was not compiled with 
DEFAULT_TO_ACCEPT...

So this idea needs more thought...

Marko




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200704180510.54729.zec>