Date: Wed, 07 Jun 2006 23:07:41 +0800 From: Julian Elischer <julian@elischer.org> To: Alex Lyashkov <shadow@psoft.net> Cc: Robert Watson <rwatson@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: jail extensions Message-ID: <4486EBBD.3090404@elischer.org> In-Reply-To: <1149692184.3224.208.camel@berloga.shadowland> References: <1149610678.4074.42.camel@berloga.shadowland> <448633F2.7030902@elischer.org> <20060607095824.W53690@fledge.watson.org> <200606070819.04301.jhb@freebsd.org> <4486E41B.4000003@elischer.org> <1149692184.3224.208.camel@berloga.shadowland>
next in thread | previous in thread | raw e-mail | index | archive | help
Alex Lyashkov wrote: >>Marco's work is somewhat similar. >>All globals related to the network are moved to structures that can be >>duplicated. >> >>The base system also uses this structure so that in effect the base >>system is just another instance >>of the virtual machines. The biggest obstacle is that the 4.x based >>version just put everything >>into one structure, meaning that it only worked when all the components >>effected were >>compiled into the kernel. None of them could be implemented as a >>loadable kernel module. >>This has become much more important in 6.x. >> >>Ther is a way to allow this to work but it would require that we >>implement a kernel version of >>the idea used for TLS (Thread Local Storage), so that modules being >>loaded could be added >>to all the existing VMs and new VMs could get instances of all loaded >>modules. >>(and so that a module could not be unloaded until all VMS have destroyed >>their instance >> >> >It`s can be created easy. each module can be full own private data and >register init/destroy methods, similar SYSINIT macro. >prison will need add array for store pointers to modules data. >yes, it possible need lost more memory - but easy for implementation. > > "Easy" if you are writing something from scratch and you want it to not be able to be compiled the old way too.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4486EBBD.3090404>