From owner-freebsd-arch@FreeBSD.ORG Fri Jul 14 20:44:28 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0334416A4DA; Fri, 14 Jul 2006 20:44:28 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACD7F43D46; Fri, 14 Jul 2006 20:44:27 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 14 Jul 2006 13:44:27 -0700 Message-ID: <44B8022A.60104@elischer.org> Date: Fri, 14 Jul 2006 13:44:26 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <1149610678.4074.42.camel@berloga.shadowland> <448633F2.7030902@elischer.org> <20060607095824.W53690@fledge.watson.org> <200606070819.04301.jhb@freebsd.org> <20060607160850.GB18940@odin.ac.hmc.edu> <20060608123125.W26068@fledge.watson.org> <20060714100333.GE3466@obiwan.tataz.chchile.org> <20060714162154.GA75657@lor.one-eyed-alien.net> In-Reply-To: <20060714162154.GA75657@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Robert Watson , Alex Lyashkov , Jeremie Le Hen , freebsd-arch@freebsd.org Subject: Re: [fbsd] Re: jail extensions 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, 14 Jul 2006 20:44:28 -0000 Brooks Davis wrote: >On Fri, Jul 14, 2006 at 12:03:33PM +0200, Jeremie Le Hen wrote: > > >>Hi, >> >>On Thu, Jun 08, 2006 at 12:32:42PM +0100, Robert Watson wrote: >> >> >>>On Wed, 7 Jun 2006, Brooks Davis wrote: >>> >>> >>> >>>>It's not clear to me that we want to use the same containers to control >>>>all resouces since you might want a set of jails sharing IPC resources or >>>>being allocated a slice of processor time to divide amongst them selves if >>>>we had a hierarchical scheduler. That said, using a single prison >>>>structure could do this if we allowed the administrator to specifiy a >>>>hierarchy of prisons and not necessicairly enclose all resources in all >>>>prisons. >>>> >>>> >>>When looking at improved virtualization support for things like System V >>>IPC, my opinion has generally been that we introduce virtualization as a >>>primitive, and then have jail use the primitive much in the same way it >>>does chroot. This leaves flexibility to use it without jail, etc, but means >>>we have a well-understood and well-defined interaction with jail. >>> >>> >>IMHO, it is worth having virtualization primitives wherever it is >>required and make jails use them. This can be the case for the >>System V IPC as well as for the network stack (think of Marko's work). >> >>My point is that the usability of virtual network stacks remains >>interesting outside the jail framework and should be able to be managed >>from its own userland tool (though the latter should probably not be >>able to destroy a virtual network stack associated with a jail). >>However I don't think that IPC are worth virtualizing outside a >>jail framework. >> >> > >I could definitly use the ability to virtualize IPC inside a lighter >container then a jail. I'd like to be able to tie them to jobs in a >batch system managed by Sun Grid Engine so I can constrain resources on >a per-job basis and insure the no IPC objects outlive the job. > >-- Brooks > > I think that the term "jail" needs to be replaced by something else in this context.. maybe a "virtual context".. virtual contexts would have the option of virtualising different parts of the system. for example they would have the option of whether or not to have a chroot, or their own networking stack, or their own process space..