vimage and modules

[George V. Neville-Neil]

At Tue, 30 Jan 2007 14:10:14 -0800,
julian wrote:
> 
> 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.

I suspect that what we need a diagram of how we think modules and
vimages relate.  Each vimage may wind up being what was called in
another system, a "protection domain" for lack of a better word.  If a
full vimage is really a copy of the whole kernel, modules and all,
then we probably need to think about a fork/exec model for kernels.
That is, creating a new vimage is the equivalent of a fork() where you
get copies of everything and some stuff is reset.  What exactly is
kept or reset is very important to work out.  I would suspect that we
would clear a lot of stuff, such as fd's, sockets etc. but keep a lot
of other state, like the RIB and FIB.

Best,
George