Date: Tue, 30 Jan 2007 14:10:14 -0800 From: Julian Elischer <julian@elischer.org> To: Marko Zec <zec@icir.org>, Robert Watson <rwatson@freebsd.org>, arch@freebsd.org Subject: vimage and modules Message-ID: <45BFC246.2000005@elischer.org>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45BFC246.2000005>