Date: Thu, 08 Feb 2007 15:50:10 -0800 From: "George V. Neville-Neil" <gnn@neville-neil.com> To: Julian Elischer <julian@elischer.org> Cc: arch@freebsd.org, Marko Zec <zec@icir.org>, Robert Watson <rwatson@freebsd.org> Subject: Re: vimage and modules Message-ID: <m2fy9gw6od.wl%gnn@neville-neil.com> In-Reply-To: <45BFC246.2000005@elischer.org> References: <45BFC246.2000005@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m2fy9gw6od.wl%gnn>