From owner-freebsd-arch@FreeBSD.ORG Fri Feb 9 00:00:47 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E042816A402 for ; Fri, 9 Feb 2007 00:00:47 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.freebsd.org (Postfix) with ESMTP id C423813C428 for ; Fri, 9 Feb 2007 00:00:47 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l18NoH6T064239; Thu, 8 Feb 2007 15:50:18 -0800 (PST) Date: Thu, 08 Feb 2007 15:50:10 -0800 Message-ID: From: "George V. Neville-Neil" To: Julian Elischer In-Reply-To: <45BFC246.2000005@elischer.org> References: <45BFC246.2000005@elischer.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.92 (i386-apple-darwin8.8.2) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: arch@freebsd.org, Marko Zec , Robert Watson Subject: Re: vimage and modules X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2007 00:00:48 -0000 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