From owner-freebsd-arch@FreeBSD.ORG Mon Jun 5 07:45:01 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 63FF516A41F for ; Mon, 5 Jun 2006 07:45:01 +0000 (UTC) (envelope-from guomingyan@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9F8843D48 for ; Mon, 5 Jun 2006 07:45:00 +0000 (GMT) (envelope-from guomingyan@gmail.com) Received: by wx-out-0102.google.com with SMTP id i31so688182wxd for ; Mon, 05 Jun 2006 00:44:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=aSxaR8bDLERhuuBQ7S71crYyTGTc8N35xzIQtfL8x2qOuCw2sFystUv43ZbxXepKVPQOhnkuornv371raUXFJPAv/5Ug4Et1Vrb94dejlXmNS4qRdANC+uwESd4y3lxpBhUibJAp9QgRSw5MVZEaPkmylV1s6859Xuvol3NJ8DA= Received: by 10.70.14.9 with SMTP id 9mr5764103wxn; Mon, 05 Jun 2006 00:44:58 -0700 (PDT) Received: by 10.70.39.18 with HTTP; Mon, 5 Jun 2006 00:44:58 -0700 (PDT) Message-ID: <1fa17f810606050044k2847e4a2i150eb934ed84006f@mail.gmail.com> Date: Mon, 5 Jun 2006 15:44:58 +0800 From: MingyanGuo To: freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: delphij@gmail.com Subject: Why use `thread' as an argument of Syscalls? 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: Mon, 05 Jun 2006 07:45:01 -0000 Hi all, I find that FreeBSD Syscalls always have an `thread' argument, for example, preadv(/sys/kern/sys_generic.c) has a `td' argument. But some Syscalls may rarely use this argument, and thay ( and functions they invoke) can get the `thread' who make the Syscall _easily_ via `curthread' macro if needed. So the `thread' argument seems not needed. Can anybody tell me why use `thread' as an argument of Syscalls? Thanks. Regards, -- Three passions, simple but overwhelmingly strong, have governed my life: the longing for love, the search for knowledge, and unbearable pity for the suffering of mankind. ---------Bertrand Russell From owner-freebsd-arch@FreeBSD.ORG Mon Jun 5 11:50:30 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 319F716A618 for ; Mon, 5 Jun 2006 11:50:30 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD2C643D67 for ; Mon, 5 Jun 2006 11:50:26 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.6/8.13.6/NETPLEX) with ESMTP id k55BoPUY011125; Mon, 5 Jun 2006 07:50:25 -0400 (EDT) Date: Mon, 5 Jun 2006 07:50:25 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: MingyanGuo In-Reply-To: <1fa17f810606050044k2847e4a2i150eb934ed84006f@mail.gmail.com> Message-ID: References: <1fa17f810606050044k2847e4a2i150eb934ed84006f@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: delphij@gmail.com, freebsd-arch@freebsd.org Subject: Re: Why use `thread' as an argument of Syscalls? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 11:50:32 -0000 On Mon, 5 Jun 2006, MingyanGuo wrote: > Hi all, > I find that FreeBSD Syscalls always have an `thread' > argument, for example, preadv(/sys/kern/sys_generic.c) > has a `td' argument. But some Syscalls may rarely use > this argument, and thay ( and functions they invoke) can > get the `thread' who make the Syscall _easily_ via > `curthread' macro if needed. So the `thread' argument > seems not needed. > Can anybody tell me why use `thread' as an argument > of Syscalls? You could have asked "why use 'proc' as an argument of Syscalls" 12 years ago (or more). When the kernel became thread-aware (almost 5 years ago), most 'struct proc' arguments were changed to 'struct thread'. -- DE From owner-freebsd-arch@FreeBSD.ORG Mon Jun 5 13:08:09 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 0030F16A739 for ; Mon, 5 Jun 2006 13:08:08 +0000 (UTC) (envelope-from guomingyan@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id C82A243D60 for ; Mon, 5 Jun 2006 13:08:04 +0000 (GMT) (envelope-from guomingyan@gmail.com) Received: by wx-out-0102.google.com with SMTP id i31so731060wxd for ; Mon, 05 Jun 2006 06:08:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=n5ZAKJUbbXEB8e/t3ilNREVTJISPJEBDZGn3NiRbuLK1pGsGEvbate0V+emJ/WRcXS/0DrGbK0Go8wH2JuwmFV60OpXROjCpSObrFGkh3MihgDTqeaM3DevD8+lLuP86wh20qtWL+33rJ07tVyzGLBDjy4W9fGUGn2kZ326YZpI= Received: by 10.70.122.15 with SMTP id u15mr3951836wxc; Mon, 05 Jun 2006 06:08:04 -0700 (PDT) Received: by 10.70.39.18 with HTTP; Mon, 5 Jun 2006 06:08:04 -0700 (PDT) Message-ID: <1fa17f810606050608l5bd2ec5ch37663375f6fa5b64@mail.gmail.com> Date: Mon, 5 Jun 2006 21:08:04 +0800 From: MingyanGuo To: "Daniel Eischen" In-Reply-To: MIME-Version: 1.0 References: <1fa17f810606050044k2847e4a2i150eb934ed84006f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: delphij@gmail.com, freebsd-arch@freebsd.org Subject: Re: Why use `thread' as an argument of Syscalls? 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: Mon, 05 Jun 2006 13:08:16 -0000 On 6/5/06, Daniel Eischen wrote: > > On Mon, 5 Jun 2006, MingyanGuo wrote: > > > Hi all, > > I find that FreeBSD Syscalls always have an `thread' > > argument, for example, preadv(/sys/kern/sys_generic.c) > > has a `td' argument. But some Syscalls may rarely use > > this argument, and thay ( and functions they invoke) can > > get the `thread' who make the Syscall _easily_ via > > `curthread' macro if needed. So the `thread' argument > > seems not needed. > > Can anybody tell me why use `thread' as an argument > > of Syscalls? > > You could have asked "why use 'proc' as an argument of Syscalls" > 12 years ago (or more). When the kernel became thread-aware > (almost 5 years ago), most 'struct proc' arguments were changed > to 'struct thread'. > > -- > DE > They are the same questions, I think ;-). Now would you please explain "why use `proc' as an argument of Syscalls" to me :)? I've read some source code of the kernel, but no comments about it found. Thanks. Regards, -- Three passions, simple but overwhelmingly strong, have governed my life: the longing for love, the search for knowledge, and unbearable pity for the suffering of mankind. ---------Bertrand Russell From owner-freebsd-arch@FreeBSD.ORG Mon Jun 5 15:19:47 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 C040D16A68C for ; Mon, 5 Jun 2006 15:19:47 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3293C43D4C for ; Mon, 5 Jun 2006 15:19:47 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.6/8.13.6/NETPLEX) with ESMTP id k55FJkKi011032; Mon, 5 Jun 2006 11:19:46 -0400 (EDT) Date: Mon, 5 Jun 2006 11:19:46 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: MingyanGuo In-Reply-To: <1fa17f810606050608l5bd2ec5ch37663375f6fa5b64@mail.gmail.com> Message-ID: References: <1fa17f810606050044k2847e4a2i150eb934ed84006f@mail.gmail.com> <1fa17f810606050608l5bd2ec5ch37663375f6fa5b64@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: delphij@gmail.com, freebsd-arch@freebsd.org Subject: Re: Why use `thread' as an argument of Syscalls? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 15:19:52 -0000 On Mon, 5 Jun 2006, MingyanGuo wrote: > On 6/5/06, Daniel Eischen wrote: >> >> On Mon, 5 Jun 2006, MingyanGuo wrote: >> >> > Hi all, >> > I find that FreeBSD Syscalls always have an `thread' >> > argument, for example, preadv(/sys/kern/sys_generic.c) >> > has a `td' argument. But some Syscalls may rarely use >> > this argument, and thay ( and functions they invoke) can >> > get the `thread' who make the Syscall _easily_ via >> > `curthread' macro if needed. So the `thread' argument >> > seems not needed. >> > Can anybody tell me why use `thread' as an argument >> > of Syscalls? >> >> You could have asked "why use 'proc' as an argument of Syscalls" >> 12 years ago (or more). When the kernel became thread-aware >> (almost 5 years ago), most 'struct proc' arguments were changed >> to 'struct thread'. >> >> -- >> DE >> > > They are the same questions, I think ;-). Now would > you please explain "why use `proc' as an argument > of Syscalls" to me :)? I've read some source code > of the kernel, but no comments about it found. I don't know. Convention? It makes sense to me. -- DE From owner-freebsd-arch@FreeBSD.ORG Mon Jun 5 15:36:43 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 2F14016A5C3; Mon, 5 Jun 2006 15:36:43 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id A55EB43D45; Mon, 5 Jun 2006 15:36:42 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 8AA0046C07; Mon, 5 Jun 2006 11:36:41 -0400 (EDT) Date: Mon, 5 Jun 2006 16:36:41 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Daniel Eischen In-Reply-To: Message-ID: <20060605163559.N50057@fledge.watson.org> References: <1fa17f810606050044k2847e4a2i150eb934ed84006f@mail.gmail.com> <1fa17f810606050608l5bd2ec5ch37663375f6fa5b64@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: MingyanGuo , delphij@gmail.com, freebsd-arch@freebsd.org Subject: Re: Why use `thread' as an argument of Syscalls? 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: Mon, 05 Jun 2006 15:36:45 -0000 On Mon, 5 Jun 2006, Daniel Eischen wrote: >> They are the same questions, I think ;-). Now would you please explain "why >> use `proc' as an argument of Syscalls" to me :)? I've read some source >> code of the kernel, but no comments about it found. > > I don't know. Convention? It makes sense to me. Certainly consistency. Most system calls do actually use the argument at some point -- be it to look up a file descriptor, access control, or the like, and the calling context has it for free and in-hand anyway. Robert N M Watson From owner-freebsd-arch@FreeBSD.ORG Mon Jun 5 15:43:01 2006 Return-Path: X-Original-To: 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 D592416A66E; Mon, 5 Jun 2006 15:43:01 +0000 (UTC) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52D6C43D45; Mon, 5 Jun 2006 15:43:01 +0000 (GMT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (localhost.csail.mit.edu [127.0.0.1]) by khavrinen.csail.mit.edu (8.13.1/8.13.4) with ESMTP id k55FgxUA079170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.csail.mit.edu issuer=Client+20CA); Mon, 5 Jun 2006 11:42:59 -0400 (EDT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.13.1/8.13.4/Submit) id k55Fgx9V079169; Mon, 5 Jun 2006 11:42:59 -0400 (EDT) (envelope-from wollman) Date: Mon, 5 Jun 2006 11:42:59 -0400 (EDT) From: Garrett Wollman Message-Id: <200606051542.k55Fgx9V079169@khavrinen.csail.mit.edu> To: rwatson@freebsd.org In-Reply-To: <20060605163559.N50057@fledge.watson.org> References: <1fa17f810606050044k2847e4a2i150eb934ed84006f@mail.gmail.com> <1fa17f810606050608l5bd2ec5ch37663375f6fa5b64@mail.gmail.com> Organization: MIT Computer Science & Artificial Intelligence Lab X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-2.0.2 (khavrinen.csail.mit.edu [127.0.0.1]); Mon, 05 Jun 2006 11:43:00 -0400 (EDT) X-Spam-Status: No, score=-0.0 required=5.0 tests=SPF_HELO_PASS,SPF_PASS version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on khavrinen.csail.mit.edu Cc: , arch@freebsd.org Subject: Re: Why use `thread' as an argument of Syscalls? 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: Mon, 05 Jun 2006 15:43:07 -0000 Robert Watson writes: >Certainly consistency. Most system calls do actually use the argument at some >point -- be it to look up a file descriptor, access control, or the like, and >the calling context has it for free and in-hand anyway. I believe it was the intention of the 4.4BSD developers to completely eliminate "curproc" (as they had already successfully eliminated "u"), on the theory that with a modern (RISC) processor architecture, passing the current process as a parameter wouldn't cost anything (since it would stay in a register for the life of the system call) whereas making a context-switched "curproc" would be expensive. -GAWollman From owner-freebsd-arch@FreeBSD.ORG Mon Jun 5 15:43:48 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 4804116A51F; Mon, 5 Jun 2006 15:43:48 +0000 (UTC) (envelope-from ssouhlal@FreeBSD.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07C4B43D45; Mon, 5 Jun 2006 15:43:47 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [172.30.10.163] (unknown [216.239.55.7]) by elvis.mu.org (Postfix) with ESMTP id C87BD1A4D86; Mon, 5 Jun 2006 08:43:46 -0700 (PDT) Message-ID: <448450FD.4030709@FreeBSD.org> Date: Mon, 05 Jun 2006 17:42:53 +0200 From: Suleiman Souhlal User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <1fa17f810606050044k2847e4a2i150eb934ed84006f@mail.gmail.com> <1fa17f810606050608l5bd2ec5ch37663375f6fa5b64@mail.gmail.com> <20060605163559.N50057@fledge.watson.org> In-Reply-To: <20060605163559.N50057@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , MingyanGuo , delphij@gmail.com, freebsd-arch@freebsd.org Subject: Re: Why use `thread' as an argument of Syscalls? 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: Mon, 05 Jun 2006 15:43:55 -0000 Robert Watson wrote: > > On Mon, 5 Jun 2006, Daniel Eischen wrote: > >>> They are the same questions, I think ;-). Now would you please >>> explain "why use `proc' as an argument of Syscalls" to me :)? I've >>> read some source code of the kernel, but no comments about it found. >> >> >> I don't know. Convention? It makes sense to me. > > > Certainly consistency. Most system calls do actually use the argument > at some point -- be it to look up a file descriptor, access control, or > the like, and the calling context has it for free and in-hand anyway. But couldn't they just use curthread/curproc? -- Suleiman From owner-freebsd-arch@FreeBSD.ORG Mon Jun 5 15:48:49 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 BE5CC16A8F7; Mon, 5 Jun 2006 15:48:49 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1200A43D58; Mon, 5 Jun 2006 15:48:48 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id EAE33170DE; Mon, 5 Jun 2006 15:48:46 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.6/8.13.6) with ESMTP id k55Fmke0044259; Mon, 5 Jun 2006 17:48:46 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Suleiman Souhlal From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 05 Jun 2006 17:42:53 +0200." <448450FD.4030709@FreeBSD.org> Date: Mon, 05 Jun 2006 17:48:46 +0200 Message-ID: <44258.1149522526@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Daniel Eischen , delphij@gmail.com, MingyanGuo , Robert Watson , freebsd-arch@FreeBSD.org Subject: Re: Why use `thread' as an argument of Syscalls? 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: Mon, 05 Jun 2006 15:48:51 -0000 In message <448450FD.4030709@FreeBSD.org>, Suleiman Souhlal writes: >Robert Watson wrote: >> >> On Mon, 5 Jun 2006, Daniel Eischen wrote: >> >>>> They are the same questions, I think ;-). Now would you please >>>> explain "why use `proc' as an argument of Syscalls" to me :)? I've >>>> read some source code of the kernel, but no comments about it found. >>> >>> >>> I don't know. Convention? It makes sense to me. >> >> >> Certainly consistency. Most system calls do actually use the argument >> at some point -- be it to look up a file descriptor, access control, or >> the like, and the calling context has it for free and in-hand anyway. > >But couldn't they just use curthread/curproc? Yes, mostly. It's a good question how much, if anything, it helps. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Mon Jun 5 15:56:10 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 D942F16B034; Mon, 5 Jun 2006 15:56:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FD8243D45; Mon, 5 Jun 2006 15:56:10 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id B599746B0E; Mon, 5 Jun 2006 11:56:05 -0400 (EDT) Date: Mon, 5 Jun 2006 16:56:06 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Suleiman Souhlal In-Reply-To: <448450FD.4030709@FreeBSD.org> Message-ID: <20060605165355.L50057@fledge.watson.org> References: <1fa17f810606050044k2847e4a2i150eb934ed84006f@mail.gmail.com> <1fa17f810606050608l5bd2ec5ch37663375f6fa5b64@mail.gmail.com> <20060605163559.N50057@fledge.watson.org> <448450FD.4030709@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Daniel Eischen , MingyanGuo , delphij@gmail.com, freebsd-arch@freebsd.org Subject: Re: Why use `thread' as an argument of Syscalls? 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: Mon, 05 Jun 2006 15:56:17 -0000 On Mon, 5 Jun 2006, Suleiman Souhlal wrote: > Robert Watson wrote: >> >> On Mon, 5 Jun 2006, Daniel Eischen wrote: >> >>>> They are the same questions, I think ;-). Now would you please explain >>>> "why use `proc' as an argument of Syscalls" to me :)? I've read some >>>> source code of the kernel, but no comments about it found. >>> >>> I don't know. Convention? It makes sense to me. >> >> Certainly consistency. Most system calls do actually use the argument at >> some point -- be it to look up a file descriptor, access control, or the >> like, and the calling context has it for free and in-hand anyway. > > But couldn't they just use curthread/curproc? In the past, in micro-benchmarking, I've measured a small performance hit from using per-cpu variables over variables already in the stack. However, that was quite a while ago, and I'm not entirely convinced the test results were valid. In the general case, it's pretty helpful to be able to pass in, for example, explicit credential references, as it means you can do acess control checks, auditing, accounting, etc, against arbitrary credentials rather than always against curthread->td_ucred. In a number of places, we pass threads down the stack where we mean to pass credentials, such as at several spots in the network stack. There are also places where the process is passed around so it can become a later argument to lockmgr() locking primitives, and since those are decreasingly used, the references are increasingly unnecessary. Robert N M Watson From owner-freebsd-arch@FreeBSD.ORG Mon Jun 5 16:30:12 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 8365416A621 for ; Mon, 5 Jun 2006 16:30:12 +0000 (UTC) (envelope-from guomingyan@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C73443D46 for ; Mon, 5 Jun 2006 16:30:11 +0000 (GMT) (envelope-from guomingyan@gmail.com) Received: by wx-out-0102.google.com with SMTP id i31so764533wxd for ; Mon, 05 Jun 2006 09:30:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=GMC0wzuZccG4viavKp6iZWVlzk+rW3Ae5FSDht3A3tOzedL3Cy9dF9t1uamOPMaUuW9BY5APo2XpmQWfO7qYq5hOvDoqr+GeivOMjkgwGsjsgloVgyj7ZwFIYL8LmdxuNQ2qu3jf547NwuK77xSEpSo1FNu+lSFlOKtXiNXZ3/0= Received: by 10.70.6.1 with SMTP id 1mr6277562wxf; Mon, 05 Jun 2006 09:30:10 -0700 (PDT) Received: by 10.70.39.18 with HTTP; Mon, 5 Jun 2006 09:30:09 -0700 (PDT) Message-ID: <1fa17f810606050930g407d622frd3568cf8036191b5@mail.gmail.com> Date: Tue, 6 Jun 2006 00:30:09 +0800 From: MingyanGuo To: freebsd-arch@freebsd.org In-Reply-To: <1fa17f810606050921n44da78d6y52f41279a0c1396b@mail.gmail.com> MIME-Version: 1.0 References: <1fa17f810606050044k2847e4a2i150eb934ed84006f@mail.gmail.com> <1fa17f810606050608l5bd2ec5ch37663375f6fa5b64@mail.gmail.com> <20060605163559.N50057@fledge.watson.org> <1fa17f810606050921n44da78d6y52f41279a0c1396b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: delphij@gmail.com Subject: Re: Why use `thread' as an argument of Syscalls? 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: Mon, 05 Jun 2006 16:30:21 -0000 On 6/5/06, Robert Watson wrote: > > > On Mon, 5 Jun 2006, Daniel Eischen wrote: > > >> They are the same questions, I think ;-). Now would you please explain > "why > >> use `proc' as an argument of Syscalls" to me :)? I've read some > source > >> code of the kernel, but no comments about it found. > > > > I don't know. Convention? It makes sense to me. > > Certainly consistency. Most system calls do actually use the argument at > some > point -- be it to look up a file descriptor, access control, or the like, > and > the calling context has it for free and in-hand anyway. > > Robert N M Watson > Thanks for your reply. And any more reasons? I have browsed some OpenSolaris and Linux source, and find that they get the `proc'/`thread'/`task' by `curproc'/`curthread'/`current' like macros when needed, which are different from FreeBSD. So I wanna know why FreeBSD do it in this way, has some mysterious reasons;-)? or not. Thanks Regards, MingyanGuo -- Three passions, simple but overwhelmingly strong, have governed my life: the longing for love, the search for knowledge, and unbearable pity for the suffering of mankind. ---------Bertrand Russell -- Three passions, simple but overwhelmingly strong, have governed my life: the longing for love, the search for knowledge, and unbearable pity for the suffering of mankind. ---------Bertrand Russell From owner-freebsd-arch@FreeBSD.ORG Mon Jun 5 17:00:31 2006 Return-Path: X-Original-To: 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 07AA016BF2E; Mon, 5 Jun 2006 17:00:31 +0000 (UTC) (envelope-from mckusick@chez.mckusick.com) Received: from chez.mckusick.com (dsl081-247-049.sfo1.dsl.speakeasy.net [64.81.247.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36F2D43D7B; Mon, 5 Jun 2006 17:00:22 +0000 (GMT) (envelope-from mckusick@chez.mckusick.com) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.13.6/8.13.1) with ESMTP id k55H0OeJ092393; Mon, 5 Jun 2006 10:00:24 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <200606051700.k55H0OeJ092393@chez.mckusick.com> To: Garrett Wollman In-Reply-To: Your message of "Mon, 05 Jun 2006 11:42:59 EDT." Date: Mon, 05 Jun 2006 10:00:24 -0700 From: Kirk McKusick Cc: arch@freebsd.org, rwatson@freebsd.org Subject: Re: Why use `thread' as an argument of Syscalls? 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: Mon, 05 Jun 2006 17:00:42 -0000 > Date: Mon, 5 Jun 2006 11:42:59 -0400 (EDT) > From: Garrett Wollman > To: rwatson@freebsd.org > Cc: arch@freebsd.org > Subject: Re: Why use `thread' as an argument of Syscalls? > > Robert Watson writes: > > >Certainly consistency. Most system calls do actually use the argument at some > >point -- be it to look up a file descriptor, access control, or the like, and > >the calling context has it for free and in-hand anyway. > > I believe it was the intention of the 4.4BSD developers to completely > eliminate "curproc" (as they had already successfully eliminated "u"), > on the theory that with a modern (RISC) processor architecture, > passing the current process as a parameter wouldn't cost anything > (since it would stay in a register for the life of the system call) > whereas making a context-switched "curproc" would be expensive. > > -GAWollman Your above analysis is correct. When we made the pass over the code base to eliminate all references to "u." we had also hoped to get rid of all references to "curproc". While we were successful with the former, it eventually became clear that the latter was not practical. But by that time, the convention of passing the current process pointer to Syscall was established, and removing it did not seem to be worth the effort. Kirk McKusick From owner-freebsd-arch@FreeBSD.ORG Mon Jun 5 17:08:43 2006 Return-Path: X-Original-To: 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 9850016AFE9; Mon, 5 Jun 2006 17:08:43 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E67B43D4C; Mon, 5 Jun 2006 17:08:43 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 022BD170DE; Mon, 5 Jun 2006 17:08:40 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.6/8.13.6) with ESMTP id k55H8c95020284; Mon, 5 Jun 2006 19:08:39 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Kirk McKusick From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 05 Jun 2006 10:00:24 PDT." <200606051700.k55H0OeJ092393@chez.mckusick.com> Date: Mon, 05 Jun 2006 19:08:38 +0200 Message-ID: <20279.1149527318@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org, Garrett Wollman , rwatson@freebsd.org Subject: Re: Why use `thread' as an argument of Syscalls? 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: Mon, 05 Jun 2006 17:08:53 -0000 In message <200606051700.k55H0OeJ092393@chez.mckusick.com>, Kirk McKusick write s: >Your above analysis is correct. When we made the pass over the code >base to eliminate all references to "u." we had also hoped to get rid >of all references to "curproc". While we were successful with the former, >it eventually became clear that the latter was not practical. But by >that time, the convention of passing the current process pointer to >Syscall was established, and removing it did not seem to be worth >the effort. It would be a good Junior Kernel Hacker project to try to replace these passed arguments with curproc and see if a measurable difference in performance is obtained. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Mon Jun 5 17:14:09 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 D9C3316BFE3 for ; Mon, 5 Jun 2006 17:14:09 +0000 (UTC) (envelope-from guomingyan@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B35243D80 for ; Mon, 5 Jun 2006 17:13:54 +0000 (GMT) (envelope-from guomingyan@gmail.com) Received: by wx-out-0102.google.com with SMTP id i31so772055wxd for ; Mon, 05 Jun 2006 10:13:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=AywXaRc6bYrktjsvAyCYmDtVhJ8yIlpotBJcSDeQILleaLrz8RaQpFAPfZVYDt7Tpg9mjRb59Xzbv4lr/5Z1aGaUVARM7Y1OV8SBku90evdqFbOLZaXl2bw1klXjs8Wv4uYSTPsnH5qSGA46lTJdswkcAqqU6gVGPOAuCJjcJoU= Received: by 10.70.59.6 with SMTP id h6mr6283148wxa; Mon, 05 Jun 2006 10:13:53 -0700 (PDT) Received: by 10.70.39.18 with HTTP; Mon, 5 Jun 2006 10:13:53 -0700 (PDT) Message-ID: <1fa17f810606051013m38cf08d7i82b6b11c7b119686@mail.gmail.com> Date: Tue, 6 Jun 2006 01:13:53 +0800 From: MingyanGuo To: "Robert Watson" In-Reply-To: <20060605165355.L50057@fledge.watson.org> MIME-Version: 1.0 References: <1fa17f810606050044k2847e4a2i150eb934ed84006f@mail.gmail.com> <1fa17f810606050608l5bd2ec5ch37663375f6fa5b64@mail.gmail.com> <20060605163559.N50057@fledge.watson.org> <448450FD.4030709@FreeBSD.org> <20060605165355.L50057@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: delphij@gmail.com, freebsd-arch@freebsd.org Subject: Re: Why use `thread' as an argument of Syscalls? 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: Mon, 05 Jun 2006 17:14:19 -0000 On 6/5/06, Robert Watson wrote: > > > On Mon, 5 Jun 2006, Suleiman Souhlal wrote: > > > Robert Watson wrote: > >> > >> On Mon, 5 Jun 2006, Daniel Eischen wrote: > >> > >>>> They are the same questions, I think ;-). Now would you please > explain > >>>> "why use `proc' as an argument of Syscalls" to me :)? I've read > some > >>>> source code of the kernel, but no comments about it found. > >>> > >>> I don't know. Convention? It makes sense to me. > >> > >> Certainly consistency. Most system calls do actually use the argument > at > >> some point -- be it to look up a file descriptor, access control, or > the > >> like, and the calling context has it for free and in-hand anyway. > > > > But couldn't they just use curthread/curproc? > > In the past, in micro-benchmarking, I've measured a small performance hit > from > using per-cpu variables over variables already in the stack. However, > that > was quite a while ago, and I'm not entirely convinced the test results > were > valid. In the general case, it's pretty helpful to be able to pass in, > for > example, explicit credential references, as it means you can do acess > control > checks, auditing, accounting, etc, against arbitrary credentials rather > than > always against curthread->td_ucred. In a number of places, we pass > threads > down the stack where we mean to pass credentials, such as at several spots > in > the network stack. There are also places where the process is passed > around > so it can become a later argument to lockmgr() locking primitives, and > since > those are decreasingly used, the references are increasingly unnecessary. > > Robert N M Watson > Thanks. MingyanGuo -- Three passions, simple but overwhelmingly strong, have governed my life: the longing for love, the search for knowledge, and unbearable pity for the suffering of mankind. ---------Bertrand Russell From owner-freebsd-arch@FreeBSD.ORG Mon Jun 5 17:22:11 2006 Return-Path: X-Original-To: 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 ECAC616A844 for ; Mon, 5 Jun 2006 17:22:11 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70EDE43D46 for ; Mon, 5 Jun 2006 17:22:11 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 53EF946C55; Mon, 5 Jun 2006 13:22:10 -0400 (EDT) Date: Mon, 5 Jun 2006 18:22:10 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <20279.1149527318@critter.freebsd.dk> Message-ID: <20060605182136.F68996@fledge.watson.org> References: <20279.1149527318@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kirk McKusick , Garrett Wollman , arch@freebsd.org Subject: Re: Why use `thread' as an argument of Syscalls? 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: Mon, 05 Jun 2006 17:22:19 -0000 On Mon, 5 Jun 2006, Poul-Henning Kamp wrote: > In message <200606051700.k55H0OeJ092393@chez.mckusick.com>, Kirk McKusick write > s: > >> Your above analysis is correct. When we made the pass over the code base to >> eliminate all references to "u." we had also hoped to get rid of all >> references to "curproc". While we were successful with the former, it >> eventually became clear that the latter was not practical. But by that >> time, the convention of passing the current process pointer to Syscall was >> established, and removing it did not seem to be worth the effort. > > It would be a good Junior Kernel Hacker project to try to replace these > passed arguments with curproc and see if a measurable difference in > performance is obtained. Caution should be applied, however: not all threads passed into functions are necessarily curthread, nor all processes curproc. It's the obscure edge places that kill you :-). Robert N M Watson From owner-freebsd-arch@FreeBSD.ORG Mon Jun 5 17:26:55 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 64B1B16A5A6 for ; Mon, 5 Jun 2006 17:26:55 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 988C043D46 for ; Mon, 5 Jun 2006 17:26:54 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by wx-out-0102.google.com with SMTP id i31so774352wxd for ; Mon, 05 Jun 2006 10:26:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=G0l6KDWilDMBe1X3v+0UJq5eeZOCAuTZpmbNJVfM3HXbSxd+JezeE7YMpQAYJhj4KseX/8eHj6nmlQcMGUecW9j2txEr1VuQbnasvfLn4I0GNkfG+yNEccGVl3DhzSa1xgqQpgYU0BYGXzJe0IvorfQENv94Rpk5QUmdUulZe/Y= Received: by 10.70.59.6 with SMTP id h6mr6296101wxa; Mon, 05 Jun 2006 10:26:53 -0700 (PDT) Received: by 10.70.37.15 with HTTP; Mon, 5 Jun 2006 10:26:53 -0700 (PDT) Message-ID: <3bbf2fe10606051026k7a9bcba4udea9ce369fea6ce4@mail.gmail.com> Date: Mon, 5 Jun 2006 19:26:53 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Poul-Henning Kamp" , freebsd-arch@freebsd.org, "Robert Watson" In-Reply-To: <20279.1149527318@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200606051700.k55H0OeJ092393@chez.mckusick.com> <20279.1149527318@critter.freebsd.dk> X-Google-Sender-Auth: da6fcc5fa0bec17e Cc: Subject: Re: Why use `thread' as an argument of Syscalls? 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: Mon, 05 Jun 2006 17:27:05 -0000 2006/6/5, Poul-Henning Kamp : > It would be a good Junior Kernel Hacker project to try to replace > these passed arguments with curproc and see if a measurable difference > in performance is obtained. There's another thing to consider: having an argument-passing structure, will improve 'reentrancy' of the kernel. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Tue Jun 6 02:14:59 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 26A0F16C2C8 for ; Tue, 6 Jun 2006 01:35:50 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 694FA43D55 for ; Tue, 6 Jun 2006 01:35:47 +0000 (GMT) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 40FADEB1127 for ; Tue, 6 Jun 2006 09:35:39 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id g3ulKCHyCkVS for ; Tue, 6 Jun 2006 09:35:34 +0800 (CST) Received: from [10.217.12.139] (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 64141EB099E for ; Tue, 6 Jun 2006 09:35:33 +0800 (CST) From: Xin LI To: freebsd-arch@FreeBSD.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-s+J6VnxokQcJXvZQ2Au8" Organization: The FreeBSD Project Date: Tue, 06 Jun 2006 09:35:29 +0800 Message-Id: <1149557729.6740.3.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 FreeBSD GNOME Team Port Cc: Subject: getbsize(3): Convert blocksizep to be unsigned long? 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: Tue, 06 Jun 2006 02:15:00 -0000 --=-s+J6VnxokQcJXvZQ2Au8 Content-Type: multipart/mixed; boundary="=-6zYcs2losBkvLFhSt+Ku" --=-6zYcs2losBkvLFhSt+Ku Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Dear folks, When I was twiddling df(1)'s code I found that getbsize(3) accepts blocksizep as long *. Because that the manual page says: "The memory referenced by blocksizep is filled in with block size, in bytes." I think it makes no sense for the number to be negative. Is it reasonable to apply the attached patch? Cheers, --=20 Xin LI http://www.delphij.net/ --=-6zYcs2losBkvLFhSt+Ku Content-Disposition: attachment; filename=patch-getbsize Content-Type: text/x-patch; name=patch-getbsize; charset=ISO-8859-1 Content-Transfer-Encoding: base64 SW5kZXg6IGluY2x1ZGUvc3RkbGliLmgNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvaG9tZS9uY3Zz L3NyYy9pbmNsdWRlL3N0ZGxpYi5oLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS42Mg0KZGlmZiAt dSAtcjEuNjIgc3RkbGliLmgNCi0tLSBpbmNsdWRlL3N0ZGxpYi5oCTE0IE1hciAyMDA2IDE2OjU3 OjMwIC0wMDAwCTEuNjINCisrKyBpbmNsdWRlL3N0ZGxpYi5oCTYgSnVuIDIwMDYgMDE6Mjc6NTYg LTAwMDANCkBAIC0yMzcsNyArMjM3LDcgQEANCiAJIGFyYzRyYW5kb20odm9pZCk7DQogdm9pZAkg YXJjNHJhbmRvbV9hZGRyYW5kb20odW5zaWduZWQgY2hhciAqZGF0LCBpbnQgZGF0bGVuKTsNCiB2 b2lkCSBhcmM0cmFuZG9tX3N0aXIodm9pZCk7DQotY2hhcgkqZ2V0YnNpemUoaW50ICosIGxvbmcg Kik7DQorY2hhcgkqZ2V0YnNpemUoaW50ICosIHVuc2lnbmVkIGxvbmcgKik7DQogCQkJCQkvKiBn ZXRjYXAoMykgZnVuY3Rpb25zICovDQogY2hhcgkqY2dldGNhcChjaGFyICosIGNvbnN0IGNoYXIg KiwgaW50KTsNCiBpbnQJIGNnZXRjbG9zZSh2b2lkKTsNCkluZGV4OiBsaWIvbGliYy9nZW4vZ2V0 YnNpemUuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL2xpYi9saWJjL2dl bi9nZXRic2l6ZS5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS43DQpkaWZmIC11IC1yMS43IGdl dGJzaXplLmMNCi0tLSBsaWIvbGliYy9nZW4vZ2V0YnNpemUuYwkzMCBEZWMgMjAwMiAxOTowNDow NiAtMDAwMAkxLjcNCisrKyBsaWIvbGliYy9nZW4vZ2V0YnNpemUuYwk2IEp1biAyMDA2IDAxOjI3 OjU2IC0wMDAwDQpAQCAtMzgsMTcgKzM4LDE2IEBADQogX19GQlNESUQoIiRGcmVlQlNEOiBzcmMv bGliL2xpYmMvZ2VuL2dldGJzaXplLmMsdiAxLjcgMjAwMi8xMi8zMCAxOTowNDowNiBvYnJpZW4g RXhwICQiKTsNCiANCiAjaW5jbHVkZSA8ZXJyLmg+DQorI2luY2x1ZGUgPGVycm5vLmg+DQogI2lu Y2x1ZGUgPHN0ZGlvLmg+DQogI2luY2x1ZGUgPHN0ZGxpYi5oPg0KICNpbmNsdWRlIDxzdHJpbmcu aD4NCiANCiBjaGFyICoNCi1nZXRic2l6ZShoZWFkZXJsZW5wLCBibG9ja3NpemVwKQ0KLQlpbnQg KmhlYWRlcmxlbnA7DQotCWxvbmcgKmJsb2Nrc2l6ZXA7DQorZ2V0YnNpemUoaW50ICpoZWFkZXJs ZW5wLCB1bnNpZ25lZCBsb25nICpibG9ja3NpemVwKQ0KIHsNCiAJc3RhdGljIGNoYXIgaGVhZGVy WzIwXTsNCi0JbG9uZyBuLCBtYXgsIG11bCwgYmxvY2tzaXplOw0KKwl1bnNpZ25lZCBsb25nIG4s IG1heCwgbXVsLCBibG9ja3NpemU7DQogCWNoYXIgKmVwLCAqcDsNCiAJY29uc3QgY2hhciAqZm9y bTsNCiANCkBAIC01OCw4ICs1NywxMSBAQA0KICNkZWZpbmUJTUFYQglHQgkJLyogTm8gdGVyYSwg cGV0YSwgbm9yIGV4YS4gKi8NCiAJZm9ybSA9ICIiOw0KIAlpZiAoKHAgPSBnZXRlbnYoIkJMT0NL U0laRSIpKSAhPSBOVUxMICYmICpwICE9ICdcMCcpIHsNCi0JCWlmICgobiA9IHN0cnRvbChwLCAm ZXAsIDEwKSkgPCAwKQ0KKwkJbiA9IHN0cnRvdWwocCwgJmVwLCAxMCk7DQorCQlpZiAoZXJybm8g PT0gRVJBTkdFKQ0KIAkJCWdvdG8gdW5kZXJmbG93Ow0KKwkJZWxzZSBpZiAoZXJybm8gPT0gRUlO VkFMKQ0KKwkJCW4gPSAwOw0KIAkJaWYgKG4gPT0gMCkNCiAJCQluID0gMTsNCiAJCWlmICgqZXAg JiYgZXBbMV0pDQo= --=-6zYcs2losBkvLFhSt+Ku-- --=-s+J6VnxokQcJXvZQ2Au8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: =?UTF-8?Q?=E8=BF=99=E6=98=AF=E4=BF=A1=E4=BB=B6=E7=9A=84=E6=95=B0?= =?UTF-8?Q?=E5=AD=97=E7=AD=BE=E5=90=8D=E9=83=A8=E5=88=86?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQBEhNvghcUczkLqiksRAmjjAKDNsWakBy90qGqYpsbXO6e9x1yhjQCg3juM 6Bx5NY/iMSdlsy69aCtj7b4= =4SjV -----END PGP SIGNATURE----- --=-s+J6VnxokQcJXvZQ2Au8-- From owner-freebsd-arch@FreeBSD.ORG Tue Jun 6 06:58:08 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 0A6D216B73B; Tue, 6 Jun 2006 06:48:13 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9576B43D45; Tue, 6 Jun 2006 06:48:12 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.4.20060308/8.13.4) with ESMTP id k566mB88046045; Mon, 5 Jun 2006 23:48:11 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.13.4.20060308/8.13.4/Submit) id k566m0df046035; Mon, 5 Jun 2006 23:48:00 -0700 (PDT) Date: Mon, 5 Jun 2006 23:48:00 -0700 (PDT) From: Matthew Dillon Message-Id: <200606060648.k566m0df046035@apollo.backplane.com> To: Alexander Leidinger References: <3bbf2fe10605311156p7e629283r34d22b368877582d@mail.gmail.com> <447DFA0C.20207@FreeBSD.org> <3bbf2fe10605311329h7adc1722j9088253515e0265b@mail.gmail.com> <20060601084052.D32549@delplex.bde.org> <3bbf2fe10605311632w58c2949buc072e58ac103d7d@mail.gmail.com> <20060601093016.ygeptkv80840gkww@netchild.homeip.net> Cc: Attilio Rao , freebsd-hackers@freebsd.org, Suleiman Souhlal , freebsd-arch@freebsd.org Subject: Re: [patch] Adding optimized kernel copying support - Part III 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: Tue, 06 Jun 2006 06:58:08 -0000 :AFAIR the DFly FPU rework allows to use FPU/XMM instructions in their :kernel without the need to do some manual state preserving (it's done :... : :Bye, :Alexander. That actually isn't quite how it works. If the userland had active FP state then the kernel still has to save it before it can use the FP registers. The kernel does not have to restore it, however (that is, it can just let userland take a fault to restore its FP state). However, the kernel still has to mess around with CR0_TS when pushing and popping an FP context / save area. The FP state reworking in DragonFly had the following effects: * We now have a save area pointer instead of a fixed, static save area. This allows FP state to be 'stacked' without having to play weird games with a static save area. * The standard FP restoration fault is no longer limited to userland. The kernel can push its own state, switch away to another thread, switch back, and take a fault to restore it, independant of the user FP state. -- It would be possible to simplify matters and actually implement what you say... the ability to use FP registers without any manual state preserving. That is, to be able to treat the FP registers just like normal registers. It would require saving and restoring a great deal more state in the interrupt/exception frame push code and the thread switch code, though. It could be conditionalized based CR0_TS or it could just be done unconditionally. I'm not sure it would yield any improvement in performance, though. There is also the problem of the storage required to manage multiple save areas. It's something like, what, 512 bytes on the stack? Because of that DragonFly still implements an FPU interlock so the kernel doesn't stack more then one additional save area due to FAST interrupts, stacked exceptions, etc. -Matt From owner-freebsd-arch@FreeBSD.ORG Tue Jun 6 07:22:59 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 9F59D16B698 for ; Tue, 6 Jun 2006 07:18:36 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id F250F43D48 for ; Tue, 6 Jun 2006 07:18:34 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by wx-out-0102.google.com with SMTP id i31so880659wxd for ; Tue, 06 Jun 2006 00:18:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=nv9DzTiuhbMsYO0/0AMHqhjwL1I9m3cPCNd1YQlt/b1V5OslIB0ALn1sCsLEdtjHB7gCipNJcpJTfSvOBlMS8a5Qb3hIvmI0h5+CpmpE5uVzCTmfr8uD6yMYUX1XQI3SWUqt2vJ1++zPTdLsTH33fCJMeWgmWeAqKP20VOuqv/8= Received: by 10.70.130.14 with SMTP id c14mr7180871wxd; Tue, 06 Jun 2006 00:18:34 -0700 (PDT) Received: by 10.70.37.15 with HTTP; Tue, 6 Jun 2006 00:18:34 -0700 (PDT) Message-ID: <3bbf2fe10606060018k7d9052eck672277079144ca10@mail.gmail.com> Date: Tue, 6 Jun 2006 09:18:34 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Matthew Dillon" , "Alexander Leidinger" , "Bruce Evans" , "Suleiman Souhlal" , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org In-Reply-To: <200606060648.k566m0df046035@apollo.backplane.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3bbf2fe10605311156p7e629283r34d22b368877582d@mail.gmail.com> <447DFA0C.20207@FreeBSD.org> <3bbf2fe10605311329h7adc1722j9088253515e0265b@mail.gmail.com> <20060601084052.D32549@delplex.bde.org> <3bbf2fe10605311632w58c2949buc072e58ac103d7d@mail.gmail.com> <20060601093016.ygeptkv80840gkww@netchild.homeip.net> <200606060648.k566m0df046035@apollo.backplane.com> X-Google-Sender-Auth: b97437906e0b7dea Cc: Subject: Re: [patch] Adding optimized kernel copying support - Part III 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: Tue, 06 Jun 2006 07:23:04 -0000 2006/6/6, Matthew Dillon : > :AFAIR the DFly FPU rework allows to use FPU/XMM instructions in their > :kernel without the need to do some manual state preserving (it's done > :... > : > :Bye, > :Alexander. > > That actually isn't quite how it works. If the userland had active > FP state then the kernel still has to save it before it can use the > FP registers. The kernel does not have to restore it, however (that is, > it can just let userland take a fault to restore its FP state). > However, the kernel still has to mess around with CR0_TS when pushing > and popping an FP context / save area. > > The FP state reworking in DragonFly had the following effects: > > * We now have a save area pointer instead of a fixed, static save area. > This allows FP state to be 'stacked' without having to play weird > games with a static save area. > > * The standard FP restoration fault is no longer limited to userland. > The kernel can push its own state, switch away to another thread, > switch back, and take a fault to restore it, independant of the > user FP state. > > -- > > It would be possible to simplify matters and actually implement what > you say... the ability to use FP registers without any manual state > preserving. That is, to be able to treat the FP registers just like > normal registers. It would require saving and restoring a great deal > more state in the interrupt/exception frame push code and the > thread switch code, though. It could be conditionalized based CR0_TS > or it could just be done unconditionally. I'm not sure it would yield > any improvement in performance, though. I tend to agree with you beacause it would be too much work/storage savings which will loose all the improvements gave to xmm registers. The point about using xmm registers is just performance improvements. I think that having an interlock into the kernel (and so just one kernel saving-state) is the better thing for performances, even if it doesn't provide a real unconditional usage. Attilio PS: Please consider too that xmm registers seem increasing performances just if used with aligned with aligned datas (movaps, movdqa), so not in the general case. MMXs, instead, seem giving very poor improvement, in particular on evolved architectures (>= P3) -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Tue Jun 6 16:18:03 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 2FA6D16B06F for ; Tue, 6 Jun 2006 16:18:03 +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 9494743D45 for ; Tue, 6 Jun 2006 16:18:02 +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 6276117000B for ; Tue, 6 Jun 2006 19:19:26 +0300 (EEST) Received: from berloga.shadowland (umka.sevcity.net [193.47.166.138]) by mail.sevcity.net (Postfix) with ESMTP id 42412170008 for ; Tue, 6 Jun 2006 19:19:26 +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 k56GHxh5007690 for ; Tue, 6 Jun 2006 19:17:59 +0300 Received: (from root@localhost) by berloga.shadowland (8.12.11.20060308/8.12.11/Submit) id k56GHwVG007688 for freebsd-arch@freebsd.org; Tue, 6 Jun 2006 19:17:58 +0300 From: Alex Lyashkov To: freebsd-arch@freebsd.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Positive Software Message-Id: <1149610678.4074.42.camel@berloga.shadowland> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-17) Date: Tue, 06 Jun 2006 19:17:58 +0300 X-Virus-Scanned: ClamAV using ClamSMTP Subject: 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: Tue, 06 Jun 2006 16:18:05 -0000 Hello All, I started to write some extension for jail. Global idea is to write the complete virtual server solutions, when each virtual server has its own resources and limits of their usage. Now implemented: - all jail code compiled under 'options JAIL' - separated uid hash - separated SYSVIPC with limit IPC objects count - process count limit At first time I plan to implement file handles limit and limit of the total disk usage per jail. project homepage http://docs.freevps.com/doku.php?id=freebsd:index -- Alex Lyashkov From owner-freebsd-arch@FreeBSD.ORG Tue Jun 6 16:31:44 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 1BC1D16BC07 for ; Tue, 6 Jun 2006 16:31:44 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFEA743D5C for ; Tue, 6 Jun 2006 16:31:42 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.13.4/8.13.3) with ESMTP id k56GVeie068818; Tue, 6 Jun 2006 20:31:40 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Tue, 6 Jun 2006 20:31:40 +0400 (MSD) From: Maxim Konovalov To: freebsd-arch@freebsd.org In-Reply-To: <1149610678.4074.42.camel@berloga.shadowland> Message-ID: <20060606202741.D67271@mp2.macomnet.net> References: <1149610678.4074.42.camel@berloga.shadowland> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Alex Lyashkov 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: Tue, 06 Jun 2006 16:31:44 -0000 On Tue, 6 Jun 2006, 19:17+0300, Alex Lyashkov wrote: > Hello All, > > I started to write some extension for jail. Global > idea is to write the complete virtual server solutions, > when each virtual server has its own resources and limits > of their usage. > Now implemented: > - all jail code compiled under 'options JAIL' > - separated uid hash > - separated SYSVIPC with limit IPC objects count > - process count limit > > At first time I plan to implement file handles limit and > limit of the total disk usage per jail. > > project homepage http://docs.freevps.com/doku.php?id=freebsd:index I'd like to clarify Alex's point a bit: he wants to know his work is acceptable by the project and could be merged. It's obvious it's almost impossible to maintain that outside of the tree. -- Maxim Konovalov From owner-freebsd-arch@FreeBSD.ORG Wed Jun 7 01:05:44 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 6258A16C319 for ; Wed, 7 Jun 2006 00:42:30 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AE6143D70 for ; Wed, 7 Jun 2006 00:42:22 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout2.pacific.net.au (Postfix) with ESMTP id B6A508F79D; Wed, 7 Jun 2006 10:41:43 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k570feZu009634; Wed, 7 Jun 2006 10:41:41 +1000 Date: Wed, 7 Jun 2006 10:41:40 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Xin LI In-Reply-To: <1149557729.6740.3.camel@spirit> Message-ID: <20060607090850.U4310@delplex.bde.org> References: <1149557729.6740.3.camel@spirit> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: getbsize(3): Convert blocksizep to be unsigned long? 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: Wed, 07 Jun 2006 01:05:44 -0000 On Tue, 6 Jun 2006, Xin LI wrote: > When I was twiddling df(1)'s code I found that getbsize(3) accepts > blocksizep as long *. Because that the manual page says: > > "The memory referenced by blocksizep is filled in with block size, in > bytes." > > I think it makes no sense for the number to be negative. Is it > reasonable to apply the attached patch? No. This mistake has been committed and backed out once too often already (in 2002). The previous interface chance was from "long *" to "size_t *". This was a larger change since it also increased the size of the pointed-to object on 64-bit machines, thus changing the ABI very unnecessarily. Using unsigned values gives sign extension bugs and breaks overflow checks that can be done in principle for sign values but not unsigned ones. df and statfs() are good examples of the sign extension bugs. statfs() used to supply correctly signed types (i.e., only signed ones), and naive users of statfs() like df still depend on this, but statfs() now supplies a mixture of signed and unsigned types, giving sign extension bugs or requiring lots of casts to avoid them when the types are mixed or unsigned values are subtracted. getbsize() still supports a correctly signed type. I use the following fix for the type error in df.c: %%% Index: df.c =================================================================== RCS file: /home/ncvs/src/bin/df/df.c,v retrieving revision 1.62 diff -u -2 -r1.62 df.c --- df.c 4 Jun 2004 09:30:51 -0000 1.62 +++ df.c 4 Jun 2004 10:15:16 -0000 @@ -363,13 +364,14 @@ prtstat(struct statfs *sfsp, struct maxwidths *mwp) { - static u_long blocksize; - static int headerlen, timesthrough = 0; - static const char *header; - int64_t used, availblks, inodes; + static long blocksize; + static int timesthrough; + const char *header; + int64_t availblks, inodes, used; + int headerlen; if (++timesthrough == 1) { mwp->mntfrom = imax(mwp->mntfrom, (int)strlen("Filesystem")); if (hflag) { - header = " Size"; + header = " Size"; mwp->total = mwp->used = mwp->avail = (int)strlen(header); @@ -440,5 +442,5 @@ update_maxwidths(struct maxwidths *mwp, const struct statfs *sfsp) { - static u_long blocksize = 0; + static long blocksize; int dummy; %%% The patch also fixes some style bugs and has part of a fix for a bug in the output formatting. "long blocksize" is now passed to fsbtoblk() which expects "u_long bs". The interface to fsbtoblk() should be changed too, but there is no actual problem due to the block size easily fitting in a signed long and fsbtoblk() defending against sign botches internally: % static intmax_t % fsbtoblk(int64_t num, uint64_t fsbs, u_long bs) % { % % if (fsbs != 0 && fsbs < bs) % return (num / (intmax_t)(bs / fsbs)); % else % return (num * (intmax_t)(fsbs / bs)); % } Note that `num' needs to be signed here since negative block counts can happen for f_bavail, and it is actually signed. It also needs to be divided by a signed value (with a positive sign) so that it doesn't get promoted to a huge unsigned value when numerator is a small signed value and the type of the denominator is unsigned and longer than the type of the numerator. This was broken in rev.1.52 when the type of fsbs (f_bsize in struct statfs) was broken from long to uint64_t. Rev.1.52 also broken type type for bs (blocksize) from long to u_long, but since u_long is smaller than uint64_t on all supported arches, this made no additional difference to the type pf (bs / fsbs) or (fsbsd / bss) -- that type is always uint64_t. Rev.1.56 works around these sign extension bugs by casting the denominator to int64_t. Rev.1.62 cleans up or down the interface of fsbtoblk() a little. Before rev.1.52, was a macro that operated only on signed types and just worked. Macros can work on "any" types provided that they don't mix unsigned types with signed ones and/or don't overflow. Overflow is avoided by not doing the multiplication (num * fsbs) first. Even this overflow avoidance is now bogus, since off_t has the same size as the block counts (all are 64 bits) so overflow can only occur if the args are garbage, so fsbtoblk() could be the even simpler macro: #define fsbtoblk(num, fsbs, bs) ((num) * (fsbs) / (bs)) provided there are no sign extension botches (the block sizes must be signed if num is signed). Casting things to signed types to avoid the sign extension bugs is worse than using signed types throughout, since it is uglier and strictly needs overflow checks for every conversion (cases where the extra bit provided by unsigned types is actually needed might cause overflow), and would require adding casts to interfaces that could be type-generic modulo signedness, and would generate larger code (see the commit log to rev.1.62). OTOH, casting everything to floating point would work well -- everything would become signed, integral values up to about 2^53 would be represented exactly, and larger values would never cause overflow and would be represented exactly enough. Befor From owner-freebsd-arch@FreeBSD.ORG Wed Jun 7 02:06:12 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 5408A16BF99 for ; Wed, 7 Jun 2006 02:03:33 +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 5EEC643D48 for ; Wed, 7 Jun 2006 02:03:33 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [192.168.3.4]) ([10.251.60.69]) by a50.ironport.com with ESMTP; 06 Jun 2006 19:03:32 -0700 Message-ID: <448633F2.7030902@elischer.org> Date: Wed, 07 Jun 2006 10:03:30 +0800 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: Maxim Konovalov References: <1149610678.4074.42.camel@berloga.shadowland> <20060606202741.D67271@mp2.macomnet.net> In-Reply-To: <20060606202741.D67271@mp2.macomnet.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Lyashkov , 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: Wed, 07 Jun 2006 02:06:13 -0000 Maxim Konovalov wrote: >On Tue, 6 Jun 2006, 19:17+0300, Alex Lyashkov wrote: > > > >>Hello All, >> >>I started to write some extension for jail. Global >>idea is to write the complete virtual server solutions, >>when each virtual server has its own resources and limits >>of their usage. >>Now implemented: >>- all jail code compiled under 'options JAIL' >>- separated uid hash >>- separated SYSVIPC with limit IPC objects count >>- process count limit >> >>At first time I plan to implement file handles limit and >>limit of the total disk usage per jail. >> >>project homepage http://docs.freevps.com/doku.php?id=freebsd:index >> >> > >I'd like to clarify Alex's point a bit: he wants to know his work is >acceptable by the project and could be merged. It's obvious it's >almost impossible to maintain that outside of the tree. > > > I'd like to see him merge his project with Marco's . If so then I'd be more than happy to see this stuff come in once it reaches a certain level of maturity. Marco and I have been going over some possible macros that could be used to help with a lot of this and if the macros were used then some of the changes could come in quite early as they would compile out to NOPs for anyone not using the changes. ( and provide an easy target for removal if it eventually doesn't complete). From owner-freebsd-arch@FreeBSD.ORG Wed Jun 7 05:59:40 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 6E8E416AA3F for ; Wed, 7 Jun 2006 05:59:40 +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 8EAA443D45 for ; Wed, 7 Jun 2006 05:59:39 +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 5FBB917000B; Wed, 7 Jun 2006 09:01:05 +0300 (EEST) Received: from berloga.shadowland (umka.sevcity.net [193.47.166.138]) by mail.sevcity.net (Postfix) with ESMTP id 1F5AD170008; Wed, 7 Jun 2006 09:01:04 +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 k575xcUu003521; Wed, 7 Jun 2006 08:59:38 +0300 Received: (from root@localhost) by berloga.shadowland (8.12.11.20060308/8.12.11/Submit) id k575xb5d003519; Wed, 7 Jun 2006 08:59:37 +0300 From: Alex Lyashkov To: Julian Elischer In-Reply-To: <448633F2.7030902@elischer.org> References: <1149610678.4074.42.camel@berloga.shadowland> <20060606202741.D67271@mp2.macomnet.net> <448633F2.7030902@elischer.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: Positive Software Message-Id: <1149659976.3224.79.camel@berloga.shadowland> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-17) Date: Wed, 07 Jun 2006 08:59:37 +0300 X-Virus-Scanned: ClamAV using ClamSMTP Cc: 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: Wed, 07 Jun 2006 06:00:01 -0000 =F7 =F3=D2=C4, 07.06.2006, =D7 05:03, Julian Elischer =D0=C9=DB=C5=D4: > Maxim Konovalov wrote: >=20 > >On Tue, 6 Jun 2006, 19:17+0300, Alex Lyashkov wrote: > > > > =20 > > > >>Hello All, > >> > >>I started to write some extension for jail. Global > >>idea is to write the complete virtual server solutions, > >>when each virtual server has its own resources and limits > >>of their usage. > >>Now implemented: > >>- all jail code compiled under 'options JAIL' > >>- separated uid hash > >>- separated SYSVIPC with limit IPC objects count > >>- process count limit > >> > >>At first time I plan to implement file handles limit and > >>limit of the total disk usage per jail. > >> > >>project homepage http://docs.freevps.com/doku.php?id=3Dfreebsd:index > >> =20 > >> > > > >I'd like to clarify Alex's point a bit: he wants to know his work is > >acceptable by the project and could be merged. It's obvious it's > >almost impossible to maintain that outside of the tree. > > > > =20 > > > I'd like to see him merge his project with Marco's . If so then I'd be=20 > more than happy > to see this stuff come in once it reaches a certain level of maturity. >=20 > Marco and I have been going over some possible macros that could be used=20 > to help with > a lot of this and if the macros were used then some of the changes could=20 > come in quite early > as they would compile out to NOPs for anyone not using the changes. > ( and provide an easy target for removal if it eventually doesn't complet= e). I focused with write flexible kernel API and create conception - any process run with own context. With 'jail2' all processes have cred->pr_prison defined. As for me it`s allow easy use struct prison as storage for any context related data such as uid hash, or diskquota hash, limits info or other. Process count limit and separated uid hash created as example to use this conception.=20 Same conception used at my other project - FreeVPS (http://www.freevps.com/tracker.html). Where i can see you and Marco work ? --=20 Alex Lyashkov From owner-freebsd-arch@FreeBSD.ORG Wed Jun 7 07:10:47 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 76DEE16C388 for ; Wed, 7 Jun 2006 07:00:45 +0000 (UTC) (envelope-from arch@dino.sk) Received: from mail.netlab.sk (mail.netlab.sk [213.215.72.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id E599143D49 for ; Wed, 7 Jun 2006 07:00:39 +0000 (GMT) (envelope-from arch@dino.sk) Received: from lex.dino.sk (home.dino.sk [213.215.74.194]) (AUTH: PLAIN milan@netlab.sk, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.netlab.sk with esmtp; Wed, 07 Jun 2006 09:00:38 +0200 id 00289C12.44867996.0000BE8B From: Milan Obuch To: freebsd-arch@freebsd.org Date: Wed, 7 Jun 2006 08:59:53 +0200 User-Agent: KMail/1.9.1 References: <1149610678.4074.42.camel@berloga.shadowland> <448633F2.7030902@elischer.org> <1149659976.3224.79.camel@berloga.shadowland> In-Reply-To: <1149659976.3224.79.camel@berloga.shadowland> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606070859.57367.arch@dino.sk> Cc: Alex Lyashkov , Julian Elischer 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: Wed, 07 Jun 2006 07:10:55 -0000 On Wednesday 07 June 2006 07:59, Alex Lyashkov wrote: > =F7 =F3=D2=C4, 07.06.2006, =D7 05:03, Julian Elischer =D0=C9=DB=C5=D4: > > Maxim Konovalov wrote: > > >On Tue, 6 Jun 2006, 19:17+0300, Alex Lyashkov wrote: > > >>Hello All, > > >> > > >>I started to write some extension for jail. Global > > >>idea is to write the complete virtual server solutions, > > >>when each virtual server has its own resources and limits > > >>of their usage. [ snip ] > > >> > > >>project homepage http://docs.freevps.com/doku.php?id=3Dfreebsd:index > > > > > >I'd like to clarify Alex's point a bit: he wants to know his work is > > >acceptable by the project and could be merged. It's obvious it's > > >almost impossible to maintain that outside of the tree. > > > > I'd like to see him merge his project with Marco's . If so then I'd be > > more than happy > > to see this stuff come in once it reaches a certain level of maturity. > > > > Marco and I have been going over some possible macros that could be used > > to help with > > a lot of this and if the macros were used then some of the changes could > > come in quite early > > as they would compile out to NOPs for anyone not using the changes. > > ( and provide an easy target for removal if it eventually doesn't > > complete). > > I focused with write flexible kernel API and create conception - any > process run with own context. With 'jail2' all processes have > cred->pr_prison defined. As for me it`s allow easy use struct prison as > storage for any context related data such as uid hash, or diskquota > hash, limits info or other. Process count limit and separated uid hash > created as example to use this conception. > Same conception used at my other project - FreeVPS > (http://www.freevps.com/tracker.html). > > Where i can see you and Marco work ? Original Marko's page is at http://www.tel.fer.hr/zec/BSD/vimage/, currentl= y=20 there is http://www.imunes.net with some related info as well. No idea on t= he=20 other work. Marko's work is 4-RELEASE bound patch, so it is not directly=20 usable, but there is some discussion on freebsd-net@ coming regularly about= =20 vrf support on FreeBSD, you can look there as well. I can only second with support to your work and test anything published=20 provided I have some time to play with it. (Not guaranteed immediately afte= r=20 publishing, but nevertheless, I am trying.) Regards, Milan =2D-=20 No need to mail me directly. Just reply to mailing list, please. From owner-freebsd-arch@FreeBSD.ORG Wed Jun 7 08:05:59 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 2E56E16C092 for ; Wed, 7 Jun 2006 07:46:44 +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 89E4E43D4C for ; Wed, 7 Jun 2006 07:46:43 +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 BC2D317000B; Wed, 7 Jun 2006 10:48:09 +0300 (EEST) Received: from berloga.shadowland (umka.sevcity.net [193.47.166.138]) by mail.sevcity.net (Postfix) with ESMTP id E6D38170008; Wed, 7 Jun 2006 10:48:08 +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 k577kg5P003859; Wed, 7 Jun 2006 10:46:42 +0300 Received: (from root@localhost) by berloga.shadowland (8.12.11.20060308/8.12.11/Submit) id k577keEF003857; Wed, 7 Jun 2006 10:46:40 +0300 From: Alex Lyashkov To: Milan Obuch In-Reply-To: <200606070859.57367.arch@dino.sk> References: <1149610678.4074.42.camel@berloga.shadowland> <448633F2.7030902@elischer.org> <1149659976.3224.79.camel@berloga.shadowland> <200606070859.57367.arch@dino.sk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Positive Software Message-Id: <1149666400.3224.123.camel@berloga.shadowland> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-17) Date: Wed, 07 Jun 2006 10:46:40 +0300 X-Virus-Scanned: ClamAV using ClamSMTP Cc: Julian Elischer , 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: Wed, 07 Jun 2006 08:06:00 -0000 > > > > I focused with write flexible kernel API and create conception - any > > process run with own context. With 'jail2' all processes have > > cred->pr_prison defined. As for me it`s allow easy use struct prison as > > storage for any context related data such as uid hash, or diskquota > > hash, limits info or other. Process count limit and separated uid hash > > created as example to use this conception. > > Same conception used at my other project - FreeVPS > > (http://www.freevps.com/tracker.html). > > > > Where i can see you and Marco work ? > > Original Marko's page is at http://www.tel.fer.hr/zec/BSD/vimage/, currently > there is http://www.imunes.net with some related info as well. No idea on the > other work. Marko's work is 4-RELEASE bound patch, so it is not directly > usable, but there is some discussion on freebsd-net@ coming regularly about > vrf support on FreeBSD, you can look there as well. > I can only second with support to your work and test anything published > provided I have some time to play with it. (Not guaranteed immediately after > publishing, but nevertheless, I am trying.) > Regards, > Milan Okey. I was look into this project over two years ago. if you can point me to discussion on freebsd-net@ i`m very interested with read this before are port network part vimage to jail2. -- Alex Lyashkov From owner-freebsd-arch@FreeBSD.ORG Wed Jun 7 08:27:01 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 713E116BC07 for ; Wed, 7 Jun 2006 08:11:57 +0000 (UTC) (envelope-from arch@dino.sk) Received: from bsd.dino.sk (bsd.dino.sk [213.215.72.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9DB043D49 for ; Wed, 7 Jun 2006 08:11:53 +0000 (GMT) (envelope-from arch@dino.sk) Received: from lex.dino.sk ([213.215.74.194]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by bsd.dino.sk with esmtp; Wed, 07 Jun 2006 10:12:20 +0200 id 00000022.44868A64.00007938 From: Milan Obuch To: Alex Lyashkov Date: Wed, 7 Jun 2006 10:11:23 +0200 User-Agent: KMail/1.9.1 References: <1149610678.4074.42.camel@berloga.shadowland> <200606070859.57367.arch@dino.sk> <1149666400.3224.123.camel@berloga.shadowland> In-Reply-To: <1149666400.3224.123.camel@berloga.shadowland> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606071011.27549.arch@dino.sk> Cc: Julian Elischer , 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: Wed, 07 Jun 2006 08:27:02 -0000 On Wednesday 07 June 2006 09:46, Alex Lyashkov wrote: > > > I focused with write flexible kernel API and create conception - any > > > process run with own context. With 'jail2' all processes have > > > cred->pr_prison defined. As for me it`s allow easy use struct prison as > > > storage for any context related data such as uid hash, or diskquota > > > hash, limits info or other. Process count limit and separated uid hash > > > created as example to use this conception. > > > Same conception used at my other project - FreeVPS > > > (http://www.freevps.com/tracker.html). > > > > > > Where i can see you and Marco work ? > > > > Original Marko's page is at http://www.tel.fer.hr/zec/BSD/vimage/, > > currently there is http://www.imunes.net with some related info as well. > > No idea on the other work. Marko's work is 4-RELEASE bound patch, so it > > is not directly usable, but there is some discussion on freebsd-net@ > > coming regularly about vrf support on FreeBSD, you can look there as > > well. > > I can only second with support to your work and test anything published > > provided I have some time to play with it. (Not guaranteed immediately > > after publishing, but nevertheless, I am trying.) > > Regards, > > Milan > > Okey. I was look into this project over two years ago. > if you can point me to discussion on freebsd-net@ i`m very interested > with read this before are port network part vimage to jail2. Two threads recorded in my personal archive - Subject: multiple routing tables, Date: 21. 03. 2006 10:22 (short) Subject: vrf support in FreeBSD Date: 09. 05. 2006 06:54 (longer, spans over two days) Maybe there were similar threads elsewhere, but I can't remember just now and I can't search deeper now. Hope this could be of some interest. Regards, Milan -- No need to mail me directly. Just reply to mailing list, please. From owner-freebsd-arch@FreeBSD.ORG Wed Jun 7 09:47:46 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 473E716C43F for ; Wed, 7 Jun 2006 08:59:19 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A99743D53 for ; Wed, 7 Jun 2006 08:59:12 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id EF4CC46C1B; Wed, 7 Jun 2006 04:59:11 -0400 (EDT) Date: Wed, 7 Jun 2006 09:59:11 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <448633F2.7030902@elischer.org> Message-ID: <20060607095824.W53690@fledge.watson.org> References: <1149610678.4074.42.camel@berloga.shadowland> <20060606202741.D67271@mp2.macomnet.net> <448633F2.7030902@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alex Lyashkov , 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: Wed, 07 Jun 2006 09:47:47 -0000 On Wed, 7 Jun 2006, Julian Elischer wrote: >> I'd like to clarify Alex's point a bit: he wants to know his work is >> acceptable by the project and could be merged. It's obvious it's almost >> impossible to maintain that outside of the tree. >> > I'd like to see him merge his project with Marco's . If so then I'd be more > than happy to see this stuff come in once it reaches a certain level of > maturity. > > Marco and I have been going over some possible macros that could be used to > help with a lot of this and if the macros were used then some of the changes > could come in quite early as they would compile out to NOPs for anyone not > using the changes. ( and provide an easy target for removal if it eventually > doesn't complete). FYI, Marko was at the FreeBSD developer summit at BSDCan, and has expressed the intent of updating his patches to 6.x/HEAD, so I think there's definitely room for collaboration here. Robert N M Watson From owner-freebsd-arch@FreeBSD.ORG Wed Jun 7 13:32:21 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 5054616BC4D; Wed, 7 Jun 2006 12:45:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7C0543D53; Wed, 7 Jun 2006 12:45:17 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k57CjAbV068753; Wed, 7 Jun 2006 08:45:13 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 7 Jun 2006 08:19:03 -0400 User-Agent: KMail/1.9.1 References: <1149610678.4074.42.camel@berloga.shadowland> <448633F2.7030902@elischer.org> <20060607095824.W53690@fledge.watson.org> In-Reply-To: <20060607095824.W53690@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606070819.04301.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 07 Jun 2006 08:45:13 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1517/Tue Jun 6 20:05:07 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Alex Lyashkov , Robert Watson , Julian Elischer 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: Wed, 07 Jun 2006 13:32:29 -0000 On Wednesday 07 June 2006 04:59, Robert Watson wrote: > > On Wed, 7 Jun 2006, Julian Elischer wrote: > > >> I'd like to clarify Alex's point a bit: he wants to know his work is > >> acceptable by the project and could be merged. It's obvious it's almost > >> impossible to maintain that outside of the tree. > >> > > I'd like to see him merge his project with Marco's . If so then I'd be more > > than happy to see this stuff come in once it reaches a certain level of > > maturity. > > > > Marco and I have been going over some possible macros that could be used to > > help with a lot of this and if the macros were used then some of the changes > > could come in quite early as they would compile out to NOPs for anyone not > > using the changes. ( and provide an easy target for removal if it eventually > > doesn't complete). > > FYI, Marko was at the FreeBSD developer summit at BSDCan, and has expressed > the intent of updating his patches to 6.x/HEAD, so I think there's definitely > room for collaboration here. What did you think about Alex's idea of a 'prison0' to for all "non-jailed" processes so that lots of things can move into 'struct prison' and not require as much special casing (though then there would be a different set of special cases I guess as prison0 would be the only prison that could create child prisons, etc.?) -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jun 7 17:06:47 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 889F516CCFA; Wed, 7 Jun 2006 14:35:14 +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 272A243D48; Wed, 7 Jun 2006 14:35:13 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [192.168.3.4]) ([10.251.60.69]) by a50.ironport.com with ESMTP; 07 Jun 2006 07:35:13 -0700 Message-ID: <4486E41B.4000003@elischer.org> Date: Wed, 07 Jun 2006 22:35:07 +0800 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: John Baldwin References: <1149610678.4074.42.camel@berloga.shadowland> <448633F2.7030902@elischer.org> <20060607095824.W53690@fledge.watson.org> <200606070819.04301.jhb@freebsd.org> In-Reply-To: <200606070819.04301.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Lyashkov , 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: Wed, 07 Jun 2006 17:07:04 -0000 John Baldwin wrote: >On Wednesday 07 June 2006 04:59, Robert Watson wrote: > > >>On Wed, 7 Jun 2006, Julian Elischer wrote: >> >> >> >>>>I'd like to clarify Alex's point a bit: he wants to know his work is >>>>acceptable by the project and could be merged. It's obvious it's almost >>>>impossible to maintain that outside of the tree. >>>> >>>> >>>> >>>I'd like to see him merge his project with Marco's . If so then I'd be >>> >>> >more > > >>>than happy to see this stuff come in once it reaches a certain level of >>>maturity. >>> >>>Marco and I have been going over some possible macros that could be used >>> >>> >to > > >>>help with a lot of this and if the macros were used then some of the >>> >>> >changes > > >>>could come in quite early as they would compile out to NOPs for anyone not >>>using the changes. ( and provide an easy target for removal if it >>> >>> >eventually > > >>>doesn't complete). >>> >>> >>FYI, Marko was at the FreeBSD developer summit at BSDCan, and has expressed >>the intent of updating his patches to 6.x/HEAD, so I think there's >> >> >definitely > > >>room for collaboration here. >> >> > >What did you think about Alex's idea of a 'prison0' to for all "non-jailed" >processes so that lots of things can move into 'struct prison' and not >require as much special casing (though then there would be a different set of >special cases I guess as prison0 would be the only prison that could create >child prisons, etc.?) > > 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 of the related object.) From owner-freebsd-arch@FreeBSD.ORG Wed Jun 7 17:23:37 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 9A7AD16DC25; Wed, 7 Jun 2006 14:56:30 +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 C726443D67; Wed, 7 Jun 2006 14:56:26 +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 383BA17000D; Wed, 7 Jun 2006 17:57:51 +0300 (EEST) Received: from berloga.shadowland (umka.sevcity.net [193.47.166.138]) by mail.sevcity.net (Postfix) with ESMTP id F2230170008; Wed, 7 Jun 2006 17:57:50 +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 k57EuPeg006104; Wed, 7 Jun 2006 17:56:25 +0300 Received: (from root@localhost) by berloga.shadowland (8.12.11.20060308/8.12.11/Submit) id k57EuOsY006102; Wed, 7 Jun 2006 17:56:24 +0300 From: Alex Lyashkov To: Julian Elischer In-Reply-To: <4486E41B.4000003@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> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Positive Software Message-Id: <1149692184.3224.208.camel@berloga.shadowland> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-17) Date: Wed, 07 Jun 2006 17:56:24 +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: Wed, 07 Jun 2006 17:23:37 -0000 > > > 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. -- Alex Lyashkov From owner-freebsd-arch@FreeBSD.ORG Wed Jun 7 17:35:53 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 14A5A16CBB6; Wed, 7 Jun 2006 15:07:46 +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 D77E343D45; Wed, 7 Jun 2006 15:07:45 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [192.168.3.4]) ([10.251.60.69]) by a50.ironport.com with ESMTP; 07 Jun 2006 08:07:43 -0700 Message-ID: <4486EBBD.3090404@elischer.org> Date: Wed, 07 Jun 2006 23:07:41 +0800 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: Alex Lyashkov 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> In-Reply-To: <1149692184.3224.208.camel@berloga.shadowland> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: Wed, 07 Jun 2006 17:36:01 -0000 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. From owner-freebsd-arch@FreeBSD.ORG Wed Jun 7 18:09:30 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 3001B16EE31; Wed, 7 Jun 2006 16:08:52 +0000 (UTC) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEA0443D45; Wed, 7 Jun 2006 16:08:51 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id k57G8ob1022112; Wed, 7 Jun 2006 09:08:50 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id k57G8oYr022111; Wed, 7 Jun 2006 09:08:50 -0700 Date: Wed, 7 Jun 2006 09:08:50 -0700 From: Brooks Davis To: John Baldwin Message-ID: <20060607160850.GB18940@odin.ac.hmc.edu> References: <1149610678.4074.42.camel@berloga.shadowland> <448633F2.7030902@elischer.org> <20060607095824.W53690@fledge.watson.org> <200606070819.04301.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oC1+HKm2/end4ao3" Content-Disposition: inline In-Reply-To: <200606070819.04301.jhb@freebsd.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new Cc: Alex Lyashkov , Robert Watson , Julian Elischer , 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: Wed, 07 Jun 2006 18:09:31 -0000 --oC1+HKm2/end4ao3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 07, 2006 at 08:19:03AM -0400, John Baldwin wrote: > On Wednesday 07 June 2006 04:59, Robert Watson wrote: > >=20 > > On Wed, 7 Jun 2006, Julian Elischer wrote: > >=20 > > >> I'd like to clarify Alex's point a bit: he wants to know his work is= =20 > > >> acceptable by the project and could be merged. It's obvious it's al= most=20 > > >> impossible to maintain that outside of the tree. > > >>=20 > > > I'd like to see him merge his project with Marco's . If so then I'd b= e=20 > more=20 > > > than happy to see this stuff come in once it reaches a certain level = of=20 > > > maturity. > > > > > > Marco and I have been going over some possible macros that could be u= sed=20 > to=20 > > > help with a lot of this and if the macros were used then some of the= =20 > changes=20 > > > could come in quite early as they would compile out to NOPs for anyon= e not=20 > > > using the changes. ( and provide an easy target for removal if it=20 > eventually=20 > > > doesn't complete). > >=20 > > FYI, Marko was at the FreeBSD developer summit at BSDCan, and has expre= ssed=20 > > the intent of updating his patches to 6.x/HEAD, so I think there's=20 > definitely=20 > > room for collaboration here. >=20 > What did you think about Alex's idea of a 'prison0' to for all "non-jaile= d"=20 > processes so that lots of things can move into 'struct prison' and not=20 > require as much special casing (though then there would be a different se= t of=20 > special cases I guess as prison0 would be the only prison that could crea= te=20 > child prisons, etc.?) 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. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --oC1+HKm2/end4ao3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFEhvoRXY6L6fI4GtQRAu1zAJ9uEPD0Qgjc6lCkwLKtPHz8GaZ/bACcD3+g o4XWkMZrftZoZ0K5qqrweK0= =Xglg -----END PGP SIGNATURE----- --oC1+HKm2/end4ao3-- From owner-freebsd-arch@FreeBSD.ORG Wed Jun 7 20:49:20 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 C2AA11703F0; Wed, 7 Jun 2006 19:03:26 +0000 (UTC) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C23643D73; Wed, 7 Jun 2006 19:03:14 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id k57J3CZp003360; Wed, 7 Jun 2006 12:03:12 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id k57J3CHw003359; Wed, 7 Jun 2006 12:03:12 -0700 Date: Wed, 7 Jun 2006 12:03:12 -0700 From: Brooks Davis To: Alex Lyashkov Message-ID: <20060607190312.GA1267@odin.ac.hmc.edu> 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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline In-Reply-To: <1149692184.3224.208.camel@berloga.shadowland> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new Cc: Robert Watson , Julian Elischer , 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: Wed, 07 Jun 2006 20:49:22 -0000 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 07, 2006 at 05:56:24PM +0300, Alex Lyashkov wrote: >=20 > >=20 > >=20 > > Marco's work is somewhat similar. > > All globals related to the network are moved to structures that can be = =20 > > duplicated. > >=20 > > The base system also uses this structure so that in effect the base=20 > > system is just another instance > > of the virtual machines. The biggest obstacle is that the 4.x based=20 > > version just put everything > > into one structure, meaning that it only worked when all the components= =20 > > effected were > > compiled into the kernel. None of them could be implemented as a=20 > > loadable kernel module. > > This has become much more important in 6.x. > >=20 > > Ther is a way to allow this to work but it would require that we=20 > > implement a kernel version of > > the idea used for TLS (Thread Local Storage), so that modules being=20 > > loaded could be added > > to all the existing VMs and new VMs could get instances of all loaded= =20 > > modules. > > (and so that a module could not be unloaded until all VMS have destroye= d=20 > > 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. Even blowing a page or two per prison probably doesn't matter. It seems unlikely anyone is going to run large numbers of them on very small platforms and it's no as if you can run a process that takes less than 3-4 pages anyway. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --0F1p//8PRICkK4MW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFEhyLvXY6L6fI4GtQRAof2AJ9HRMIE0QfyNbTjTWd0ahgJVZUcPACguRUS 4W/Xtq8nFuLrvwFWE9DnuJQ= =27xr -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW-- From owner-freebsd-arch@FreeBSD.ORG Thu Jun 8 10:37:52 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 7219416BDE9; Thu, 8 Jun 2006 09:01:29 +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 8CD6E43D45; Thu, 8 Jun 2006 09:01:27 +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 5FC7D17000F; Thu, 8 Jun 2006 12:02:56 +0300 (EEST) Received: from berloga.shadowland (umka.sevcity.net [193.47.166.138]) by mail.sevcity.net (Postfix) with ESMTP id 2F70A170007; Thu, 8 Jun 2006 12:02: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 k5891V1p004391; Thu, 8 Jun 2006 12:01:31 +0300 Received: (from root@localhost) by berloga.shadowland (8.12.11.20060308/8.12.11/Submit) id k5891U1c004389; Thu, 8 Jun 2006 12:01:30 +0300 From: Alex Lyashkov To: Julian Elischer In-Reply-To: <4486EBBD.3090404@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> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable Organization: Positive Software Message-Id: <1149757290.3222.44.camel@berloga.shadowland> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-17) Date: Thu, 08 Jun 2006 12:01:30 +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: Thu, 08 Jun 2006 10:37:58 -0000 =F7 =F3=D2=C4, 07.06.2006, =D7 18:07, Julian Elischer =D0=C9=DB=C5=D4: > Alex Lyashkov wrote: >=20 > >>Marco's work is somewhat similar. > >>All globals related to the network are moved to structures that can be = =20 > >>duplicated. > >> > >>The base system also uses this structure so that in effect the base=20 > >>system is just another instance > >>of the virtual machines. The biggest obstacle is that the 4.x based=20 > >>version just put everything > >>into one structure, meaning that it only worked when all the components= =20 > >>effected were > >>compiled into the kernel. None of them could be implemented as a=20 > >>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=20 > >>implement a kernel version of > >>the idea used for TLS (Thread Local Storage), so that modules being=20 > >>loaded could be added > >>to all the existing VMs and new VMs could get instances of all loaded=20 > >>modules. > >>(and so that a module could not be unloaded until all VMS have destroye= d=20 > >>their instance > >> =20 > >> > >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. > > =20 > > >=20 > "Easy" if you are writing something from scratch and you want it to not=20 > be able to be compiled > the old way too. what you implicit as 'old way' ? I think module will be have 2 way init - one for old SYSINIT() who called module_init(&prison0), and additional JAILINIT() who call module_init(struct prisoin *) for init private data from new prisons.=20 for dynamically loaded modules can be 2 ways. 1) if modules loaded - init private data only for (prison0) and wait for 'kldload' from other contexts, where call module_init(struct prisoin *). At this way me simulate 'kldload' for modules. 2) at MOD_LOAD case run loop for each prisons and init private data for this module at all contexts. At this way module always 'exist' at all contexts. and disable module compiling (loading) when module don`t marked jail safe. --=20 FreeVPS Developers Team http://www.freevps.com Positive Software http://www.psoft.net From owner-freebsd-arch@FreeBSD.ORG Thu Jun 8 13:46:17 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 B9EA316C646; Thu, 8 Jun 2006 11:32:43 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 384B243D5C; Thu, 8 Jun 2006 11:32:43 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 6E79146BB8; Thu, 8 Jun 2006 07:32:42 -0400 (EDT) Date: Thu, 8 Jun 2006 12:32:42 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Brooks Davis In-Reply-To: <20060607160850.GB18940@odin.ac.hmc.edu> Message-ID: <20060608123125.W26068@fledge.watson.org> 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alex Lyashkov , Julian Elischer , 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: Thu, 08 Jun 2006 13:46:17 -0000 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. Robert N M Watson From owner-freebsd-arch@FreeBSD.ORG Thu Jun 8 18:10:56 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 19F2216FE77; Thu, 8 Jun 2006 17:11:44 +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 568C343D49; Thu, 8 Jun 2006 17:11:34 +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 3885117000F; Thu, 8 Jun 2006 20:13:02 +0300 (EEST) Received: from berloga.shadowland (umka.sevcity.net [193.47.166.138]) by mail.sevcity.net (Postfix) with ESMTP id C04F6170007; Thu, 8 Jun 2006 20:13:01 +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 k58HBc0t024118; Thu, 8 Jun 2006 20:11:38 +0300 Received: (from root@localhost) by berloga.shadowland (8.12.11.20060308/8.12.11/Submit) id k58HBbTE024116; Thu, 8 Jun 2006 20:11:37 +0300 From: Alex Lyashkov To: Julian Elischer In-Reply-To: <1149757290.3222.44.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> <4486EBBD.3090404@elischer.org> <1149757290.3222.44.camel@berloga.shadowland> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Positive Software Message-Id: <1149786697.3222.91.camel@berloga.shadowland> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-17) Date: Thu, 08 Jun 2006 20:11:37 +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: Thu, 08 Jun 2006 18:10:59 -0000 > 2) at MOD_LOAD case run loop for each prisons and init private data for > this module at all contexts. At this way module always 'exist' at all > contexts. > and disable module compiling (loading) when module don`t marked jail > safe. example for this way. http://cvs.freevps.com/index.cgi/kernel/include/linux/freevps/s_context_xfrm.h?rev=1.3 http://cvs.freevps.com/index.cgi/kernel/net/ipv4/ah4.c?rev=1.3 ah4_init/ah4_fini functions. -- Alex Lyashkov From owner-freebsd-arch@FreeBSD.ORG Fri Jun 9 13:24:48 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 20C0516A41A; Fri, 9 Jun 2006 13:24:48 +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 774D743D8F; Fri, 9 Jun 2006 13:24:38 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [192.168.3.4]) ([10.251.60.61]) by a50.ironport.com with ESMTP; 09 Jun 2006 06:24:36 -0700 Message-ID: <44897693.5050306@elischer.org> Date: Fri, 09 Jun 2006 21:24:35 +0800 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: Alex Lyashkov 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> In-Reply-To: <1149786697.3222.91.camel@berloga.shadowland> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 09 Jun 2006 13:24:48 -0000 Alex Lyashkov wrote: >>2) at MOD_LOAD case run loop for each prisons and init private data for >>this module at all contexts. At this way module always 'exist' at all >>contexts. >>and disable module compiling (loading) when module don`t marked jail >>safe. >> >> >example for this way. >http://cvs.freevps.com/index.cgi/kernel/include/linux/freevps/s_context_xfrm.h?rev=1.3 >http://cvs.freevps.com/index.cgi/kernel/net/ipv4/ah4.c?rev=1.3 >ah4_init/ah4_fini functions. > > this is the bit that is obvious. The hard bit is the non obvious difficulty of changing all existing modules in such away that they can be compiled both in the new way, and in a way that they are still compiled to the old way. You need to put all the currently global variables into a structure that can be instantiated for each jail, but in order to make this continue to work in the existing system, they still need to be compiled as a global when the normal buold is made. for this reason Marco and I were looking at various macros that can be defined to allow the variables to be compiled both ways. For example : int xx; static int yy; struct a { int aa; int bb; } cc; might become: VM_GLOBAL_START(modname) int xx; VMG_STATIC int yy; struct a { int aa; int bb; } cc; VM_GLOBAL_STOP(modname) You would access these as: VM_GLOBAL(modname, yy) = 2 foobar( VM_GLOBAL_STRUCT(cc, modname)->bb); or similar. From owner-freebsd-arch@FreeBSD.ORG Fri Jun 9 14:16:35 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 BEB1E16A41A; Fri, 9 Jun 2006 14:16:35 +0000 (UTC) (envelope-from zec@icir.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12A7F43D72; Fri, 9 Jun 2006 14:16:35 +0000 (GMT) (envelope-from zec@icir.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id 3F76E9B655; Fri, 9 Jun 2006 16:16:33 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.1 Received: from [192.168.200.106] (zec2.tel.fer.hr [161.53.19.79]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 3B2839B649; Fri, 9 Jun 2006 16:16:18 +0200 (CEST) From: Marko Zec To: freebsd-arch@freebsd.org Date: Fri, 9 Jun 2006 16:16:14 +0000 User-Agent: KMail/1.9.1 References: <1149610678.4074.42.camel@berloga.shadowland> <1149786697.3222.91.camel@berloga.shadowland> <44897693.5050306@elischer.org> In-Reply-To: <44897693.5050306@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606091616.15042.zec@icir.org> Cc: Alex Lyashkov , Robert Watson , Julian Elischer 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: Fri, 09 Jun 2006 14:16:35 -0000 On Friday 09 June 2006 13:24, Julian Elischer wrote: > Alex Lyashkov wrote: > >>2) at MOD_LOAD case run loop for each prisons and init private data for > >>this module at all contexts. At this way module always 'exist' at all > >>contexts. > >>and disable module compiling (loading) when module don`t marked jail > >>safe. > > > >example for this way. > >http://cvs.freevps.com/index.cgi/kernel/include/linux/freevps/s_context_xf > >rm.h?rev=1.3 > > http://cvs.freevps.com/index.cgi/kernel/net/ipv4/ah4.c?rev=1.3 > >ah4_init/ah4_fini functions. > > this is the bit that is obvious. > > The hard bit is the non obvious difficulty of changing all existing > modules in such away that > they can be compiled both in the new way, and in a way that they are > still compiled to the old way. > > You need to put all the currently global variables into a structure that > can be instantiated > for each jail, but in order to make this continue to work in the > existing system, they still need to > be compiled as a global when the normal buold is made. > > for this reason Marco and I were looking at various macros that can be > defined to > allow the variables to be compiled both ways. > > For example : > > > int xx; > static int yy; > struct a { > int aa; > int bb; > } cc; > > might become: > > VM_GLOBAL_START(modname) > int xx; > VMG_STATIC int yy; > struct a { > int aa; > int bb; > } cc; > VM_GLOBAL_STOP(modname) > > > You would access these as: > VM_GLOBAL(modname, yy) = 2 > foobar( VM_GLOBAL_STRUCT(cc, modname)->bb); One of the questions I have no answers to is what should we do with the "static" modifier semantics in a virtualized world order. I.e. once th e virtualized symbols are placed in a structure generated by whatever macros we design, it will become difficult to efficiently discriminate between globally and locally visible parts of that structure... Marko From owner-freebsd-arch@FreeBSD.ORG Sat Jun 10 19:09:59 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 CBE1916A57E for ; Sat, 10 Jun 2006 19:09:59 +0000 (UTC) (envelope-from post@schmixfilm.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 262C7459A3 for ; Sat, 10 Jun 2006 10:21:07 +0000 (GMT) (envelope-from post@schmixfilm.de) Received: from [80.131.4.74] (helo=schmix_rechner) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1Fp0aW3xH7-0000nK; Sat, 10 Jun 2006 12:21:07 +0200 From: "schmix_film" To: freebsd-arch@FreeBSD.org Date: Sat, 10 Jun 2006 12:23:05 +0200 X-Priority: 1 X-Library: Indy 8.0.25 Message-ID: <0MKwtQ-1Fp0aW3xH7-0000nK@mrelayeu.kundenserver.de> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b6bc863ac860afc188ef3138cc4ecceb MIME-Version: 1.0 Content-Type: text/plain; iso-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Weltmeister [schmix_film feat. Lax Alex Contrax] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: post@schmixfilm.de List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 19:10:00 -0000 Leckomio, liebe Wartenden! Die Heiopeis vom Niederrhein haben es mit viel Ramba-Zamba wieder mal auf den letzten Drücker geschafft: Nach zahlreichen Nächten im Atelier der Alberei kommt nun doch noch pünktlich der schmix_film-Beitrag zur WM. Unsere zwei frechen Himmelhunde spielen diesmal acht (in Worten: acht!) Charaktere im Clip zum brandneuen "Weltmeister"-Song von Lax Alex Contrax. Klemmi aus "Stille Wasser" ist wieder dabei, aber auch Jochen, Zecki und Herr Berg bekommen ihre 3 Minuten Ruhm. Für knisternde Erotik sorgen zwei hemmungslose Trikot-Luder mit tollen Tröten. Doch der großen Worte seien genug gewechselt - Ball frei für die spielerisch wohl beste deutsche Acht aller Zeiten Vorführung im Online-Kino -> [1]http://www.schmixfilm.de/kino_weltmeister_start.html Direkt-Link zum Clip -> : [2]http://62.75.215.190/schmix/weltmeister.mpg [3]http://www.schmixfilm.de/kino_weltmeister_start.html http://www.schmixfilm.de/kino_weltmeister_start.html Dear waiting ones! After numerous nights in their creepy laboratories those german semi-nerds from schmixfilm finally did it again and right on time we are now proud to present you their contribution to the World Cup 2006. This time they shake their hips to the inofficial World Cup-anthem Weltmeister from Germanys Ska-heroes Lax Alex! Enough of the boring blabla: Kick it with probably the best German eight of all times! online presentaion in cinema -> [4]http://www.schmixfilm.de/kino_weltmeister_start.html direct link to clip -> : [5]http://62.75.215.190/schmix/weltmeister.mpg References 1. http://www.schmixfilm.de/kino_weltmeister_start.html 2. http://62.75.215.190/schmix/weltmeister.mpg 3. http://www.schmixfilm.de/kino_weltmeister_start.html 4. http://www.schmixfilm.de/kino_weltmeister_start.html 5. http://62.75.215.190/schmix/weltmeister.mpg From owner-freebsd-arch@FreeBSD.ORG Sat Jun 10 19:52:34 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 4558316A47F; Sat, 10 Jun 2006 19:52:34 +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 5C1EF43D73; Sat, 10 Jun 2006 19:52:33 +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 181EF170010; Sat, 10 Jun 2006 22:54:09 +0300 (EEST) Received: from berloga.shadowland (umka.sevcity.net [193.47.166.138]) by mail.sevcity.net (Postfix) with ESMTP id DBD2C170004; Sat, 10 Jun 2006 22:54:06 +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 k5AJqk4c016107; Sat, 10 Jun 2006 22:52:46 +0300 Received: (from root@localhost) by berloga.shadowland (8.12.11.20060308/8.12.11/Submit) id k5AJqis0016105; Sat, 10 Jun 2006 22:52:44 +0300 From: Alex Lyashkov To: Julian Elischer In-Reply-To: <44897693.5050306@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> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable Organization: Positive Software Message-Id: <1149969164.3215.66.camel@berloga.shadowland> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-17) Date: Sat, 10 Jun 2006 22:52:44 +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: Sat, 10 Jun 2006 19:52:34 -0000 =F7 =F0=D4=CE, 09.06.2006, =D7 16:24, Julian Elischer =D0=C9=DB=C5=D4: > Alex Lyashkov wrote: >=20 > >>2) at MOD_LOAD case run loop for each prisons and init private data for > >>this module at all contexts. At this way module always 'exist' at all > >>contexts. > >>and disable module compiling (loading) when module don`t marked jail > >>safe. > >> =20 > >> > >example for this way. > >http://cvs.freevps.com/index.cgi/kernel/include/linux/freevps/s_context_= xfrm.h?rev=3D1.3 > >http://cvs.freevps.com/index.cgi/kernel/net/ipv4/ah4.c?rev=3D1.3 > >ah4_init/ah4_fini functions. > > =20 > > >=20 > this is the bit that is obvious. >=20 > The hard bit is the non obvious difficulty of changing all existing=20 > modules in such away that > they can be compiled both in the new way, and in a way that they are=20 > still compiled to the old way. >=20 > You need to put all the currently global variables into a structure that=20 > can be instantiated > for each jail, but in order to make this continue to work in the=20 > existing system, they still need to > be compiled as a global when the normal buold is made. >=20 > for this reason Marco and I were looking at various macros that can be=20 > defined to > allow the variables to be compiled both ways. >=20 > For example : >=20 >=20 > int xx; > static int yy; > struct a { > int aa; > int bb; > } cc; >=20 > might become: >=20 > VM_GLOBAL_START(modname) > int xx; > VMG_STATIC int yy; > struct a { > int aa; > int bb; > } cc; > VM_GLOBAL_STOP(modname) >=20 >=20 > You would access these as: > VM_GLOBAL(modname, yy) =3D 2 > foobar( VM_GLOBAL_STRUCT(cc, modname)->bb); >=20 > or similar. >=20 >=20 >=20 And I can`t find any benefits of give up old way when create=20 per module=20 struct module_data_$name { int xx; int yy; struct a { int aa; int bb; } cc; }; and use access as $name_data(context, yy) =3D 2. for non jail kernel it`s should be converted to always access via prison0.=20 main difficulty is convert access to variables to use macros, not are create struct. is anybody can review my patch and point me any wrong parts ? --=20 Alex Lyashkov