From owner-freebsd-arch@FreeBSD.ORG Sun Jun 11 17:23:23 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 0238316A418; Sun, 11 Jun 2006 17:23:23 +0000 (UTC) (envelope-from shadow@psoft.net) Received: from mail.sevcity.net (ns.sevcity.net [193.47.166.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B0F643D46; Sun, 11 Jun 2006 17:23:19 +0000 (GMT) (envelope-from shadow@psoft.net) Received: from mail.sevcity.net (service.sevcity [127.0.0.1]) by mail.sevcity.net (Postfix) with ESMTP id 562BB170009; Sun, 11 Jun 2006 20:24:56 +0300 (EEST) Received: from berloga.shadowland (umka.sevcity.net [193.47.166.138]) by mail.sevcity.net (Postfix) with ESMTP id 1F55B170004; Sun, 11 Jun 2006 20:24:55 +0300 (EEST) Received: from berloga.shadowland (berloga.shadowland [127.0.0.1]) by berloga.shadowland (8.12.11.20060308/8.12.11) with ESMTP id k5BHNE9T021378; Sun, 11 Jun 2006 20:23:15 +0300 Received: (from root@localhost) by berloga.shadowland (8.12.11.20060308/8.12.11/Submit) id k5BHNDD4021374; Sun, 11 Jun 2006 20:23:13 +0300 From: Alex Lyashkov To: Julian Elischer In-Reply-To: <448B8B7A.1020008@elischer.org> 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> <4486EBBD.3090404@elischer.org> <1149757290.3222.44.camel@berloga.shadowland> <1149786697.3222.91.camel@berloga.shadowland> <44897693.5050306@elischer.org> <1149969164.3215.66.camel@berloga.shadowland> <448B8B7A.1020008@elischer.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Positive Software Message-Id: <1150046593.3315.18.camel@berloga.shadowland> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-17) Date: Sun, 11 Jun 2006 20:23:13 +0300 X-Virus-Scanned: ClamAV using ClamSMTP Cc: Robert Watson , freebsd-arch@freebsd.org Subject: 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: Sun, 11 Jun 2006 17:23:23 -0000 > > It's not a technical problem. > > It's the fact that when we introduce these things we always try to do > it is a way so > that there is a period where both old and new can co-exist. > > It would also be useful to have a set of macros (similar to the current > SYSINIT) > that make this easy to do. > > If you do this then you are adding two indirections to every global access > as you need to access the struct via the current jail. > > people who compile this out are not likely to want to have that set of > indirections > for no purpose, especially during the settl-down eriod when it is new. > > If you want to not make it optional then, yes, but that in general is > not how most large new > work is done. And expect people to complain bitterly about any slow-down > you introduce for > people who don't want that fearture. ESPECIALLY in networking. > my change log has record - 'option JAIL' added to kernel config, without it - kernel build at "old" way. In future, after all of need modules will be rewrite to support jail, - this behaviour can be changed and to disable only codepath where jail add overhead (for my FreeVPS project it`s only L2 routing for separate packets between context) or disable code only used with jail. -- FreeVPS Developers Team http://www.freevps.com Positive Software http://www.psoft.net