Date: Fri, 29 Jun 2001 13:34:19 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Nicolas Souchu <nsouch@fr.alcove.com> Cc: <freebsd-hackers@freebsd.org> Subject: Re: processes private data Message-ID: <Pine.BSF.4.33.0106291329580.2969-100000@herring.nlsystems.com> In-Reply-To: <20010629110607.B19935@avon.alcove-fr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 29 Jun 2001, Nicolas Souchu wrote: > 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: When you get a new struct file from falloc(), VFS has nothing to do with it. As you can see from the streamsopen() code, you can change f_ops (which by default points at &badfileops) and f_data (defaults to zero) to point at your own functions and data. The point is that you are creating a new file. The VFS-owned file which ended up calling the open driver entrypoint will be discarded in favour of your new one. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.33.0106291329580.2969-100000>