From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 18:58:23 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E45C16A41C; Mon, 13 Jun 2005 18:58:23 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1B8143D1F; Mon, 13 Jun 2005 18:58:22 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j5DJ34Q3006004; Mon, 13 Jun 2005 13:03:05 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42ADD6AC.3060505@samsco.org> Date: Mon, 13 Jun 2005 12:55:40 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig References: <42ADC762.6010801@elischer.org> <20050613181435.GA3096@infradead.org> <42ADD253.4020606@samsco.org> <20050613184551.GA3853@infradead.org> In-Reply-To: <20050613184551.GA3853@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: Daniel Eischen , freebsd-hackers@freebsd.org, Julian Elischer , Apache Xie Subject: Re: contigmalloc() and mmap() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2005 18:58:23 -0000 Christoph Hellwig wrote: > On Mon, Jun 13, 2005 at 12:37:07PM -0600, Scott Long wrote: > >>How does linux handle the implications of fork(2) in this scenario? > > > it's still counted as the same instance. Similar for dup or passing > descriptors over AF_UNIX sockets. The data is explictly not per-process > but per instance. > > There's not a lot of users actually using this feature, only the tty > subsystem and multi-channel sound drivers for the old oss API that > allowed multiple opens of /dev/dsp that way come to mind. > > Lot's of driver use file->private to get at per-device data easily, > but that's just a shortcut. Ok, I thought that you were talking about per-process data being in the file descriptor. Scott