PERFORCE change 118226 for review
Marko Zec
zec at icir.org
Wed Apr 18 03:30:26 UTC 2007
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
More information about the p4-projects
mailing list