vimage and modules

Julian Elischer julian at elischer.org
Tue Jan 30 22:25:01 UTC 2007


I've looked at the current vimage code and I'm impressed.

The question remains to me that we need to have vimage and modules
interact well.

One question is, "should existing vimages suddenly get
new capabilities when new kernel modules are loaded?"
One alternative is to only  allow them to have access to modules that 
were loaded before the creation of the vimage.

An analogy in the TLS (thread-local storage) world is that
when a new shared library is loaded, TLS variables are
immediately available to it. However this may not be needed
in a virtual machine.

I heard someone mention the following idea in passing and the
more I think about it, the more I like it..

Virtual machines are 'booted without loaded modules.'
They have however, available to them all the modules loaded
into the base system at the time that they are looking, and
can 'load them' just as the base system can load kernel
modules.

The difference is that they are not able to load new modules,
but rather, only to do the 'vm_linkage' stage required on already
loaded modules.

The vm linkage would be a separate subset of what needs to
be done when a module is loaded. It would be a separate
entry-point that would only be present on modules that
supported vimages.

An example would be some module 'x'.

It would have a function that would set up any
per-vimage linkages needed (mallocing and linking
its own vimage-specific variables structure into the
list of modules for that vimage.

Currently we have a load and unload method. This would
suggest adding a vm_load method as well. creating a new
vimage could run through all the existing modules, and
call that functions, or we could do it as part of the booting of the 
vimage from (say) /etc/rc or similar.


If a module had no vimage-specific behaviour it would
not have the extra entry-point.

It does mean that we need to look at the inter-module
dependencies as if you wanted to have one module call into
another, you'd need to have dependencies well documented. In
the current code you get a linkage failure, if there are
global variables accessed between them but with a 'per vmimage'
structure of variables this becomes a runtime problem, unless
we explicitly have the dependencies registered.


More information about the freebsd-arch mailing list