From owner-freebsd-hackers Fri Jun 29 2:16: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.alcove.fr (smtp.alcove.fr [212.155.209.139]) by hub.freebsd.org (Postfix) with ESMTP id 214A737B40C for ; Fri, 29 Jun 2001 02:16:00 -0700 (PDT) (envelope-from nsouch@alcove.fr) Received: from avon.alcove-fr ([10.16.10.3]) by smtp.alcove.fr with esmtp (Exim 3.12 #1 (Debian)) id 15FuE4-0002zg-00; Fri, 29 Jun 2001 11:06:08 +0200 Received: from nsouch by avon.alcove-fr with local (Exim 3.12 #1 (Debian)) id 15FuE3-0005R3-00; Fri, 29 Jun 2001 11:06:07 +0200 Date: Fri, 29 Jun 2001 11:06:07 +0200 From: Nicolas Souchu To: Doug Rabson Cc: freebsd-hackers@freebsd.org Subject: Re: processes private data Message-ID: <20010629110607.B19935@avon.alcove-fr> References: <20010628182533.B17804@avon.alcove-fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.4i In-Reply-To: ; from dfr@nlsystems.com on Thu, Jun 28, 2001 at 07:48:21PM +0100 Organization: =?iso-8859-1?Q?Alc=F4ve=2C_http:=2F=2Fwww=2Ealcove=2Ecom?= Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Jun 28, 2001 at 07:48:21PM +0100, Doug Rabson wrote: > On Thu, 28 Jun 2001, Nicolas Souchu wrote: > > > Hi folks, > > > > I have a char driver that must be opened by more than one process. The minor > > index is not sufficient for this. Is there any process private data (void *) > > in the devfs structure (or the opposite) I could point to with the minor index > > of my device? > > The only way I know of to do this is to get a new struct file with > falloc() and install your own fileops. You can then set p->p_dupfd to the > new file descriptor and return ENXIO. The caller will magically use the > new struct file. For an example, see streamsopen() in > sys/dev/streams/streams.c. Ok, it seems to do part of the job. But this won't change the content of the file struct. Does anything ensure that the f_data of the freshly allocated struct file won't be used by vfs? Is the new struct file only local to my device driver? Otherwise, I could write my own falloc() which would allocate a struct file compatible with the original one like this: struct my_file { struct file original; void *my_private; ... }; Nicholas -- Alcôve Technical Manager - Nicolas.Souchu@fr.alcove.com - http://www.alcove.com Open Source Software Developer - nsouch@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message