Date: Fri, 29 Jun 2001 11:06:07 +0200 From: Nicolas Souchu <nsouch@fr.alcove.com> To: Doug Rabson <dfr@nlsystems.com> Cc: freebsd-hackers@freebsd.org Subject: Re: processes private data Message-ID: <20010629110607.B19935@avon.alcove-fr> In-Reply-To: <Pine.BSF.4.33.0106281944210.866-100000@herring.nlsystems.com>; from dfr@nlsystems.com on Thu, Jun 28, 2001 at 07:48:21PM %2B0100 References: <20010628182533.B17804@avon.alcove-fr> <Pine.BSF.4.33.0106281944210.866-100000@herring.nlsystems.com>
index | next in thread | previous in thread | raw e-mail
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
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010629110607.B19935>