Date: Thu, 17 May 2001 21:03:44 +0100 From: Brian Somers <brian@Awfulhak.org> To: Peter Wemm <peter@wemm.org> Cc: Brian Somers <brian@Awfulhak.org>, Poul-Henning Kamp <phk@critter.freebsd.dk>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, brian@Awfulhak.org Subject: Re: cvs commit: src/sys/fs/devfs devfs_vnops.c Message-ID: <200105172003.f4HK3ib68172@hak.lan.Awfulhak.org> In-Reply-To: Message from Peter Wemm <peter@wemm.org> of "Thu, 17 May 2001 12:19:22 PDT." <20010517191922.B6C4D380A@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> Brian Somers wrote:
> > > >> Revision Changes Path
> > > >> 1.23 +7 -15 src/sys/fs/devfs/devfs_vnops.c
> > > >
> > > >Does this mean that I can catch ``open("/dev/tun")'' and clone (say)
> > > >/dev/tun100, returning that ?
> > >
> > > yes :-)
> >
> > I think the only thing that's missing is that you can't have the
> > clone handler called for an existing device node.
> >
> > I'd like to be able to make_dev() /dev/tun during attach and allow
> > the sysadmin (or whatever) to change it's permissions. Then, when an
> > attempt to open it is made, have my clone handler called. My clone
> > handler make_dev()s /dev/tunN and returns that. When /dev/tunN's
> > final close is done, I destroy_dev() it.
> >
> > Unfortunately, I don't think this can be done very easily. We'd need
> > to allocate a new vnode only at open time - probably in vn_open.
> > It'd probably be convenient if devfs was able to set some new vnode
> > flag in vnodes returned from it's lookup based on some flag passed
> > into make_dev() (oops, there are no flags there). When vn_open()
> > sees the flag, it calls some registered handler that goes off and
> > returns either the original vnode or (if successfully cloned) a new
> > vnode.
> >
> > Does any of that make sense ?
>
> It does make sense, but are you sure it's needed? The clone device (/dev/
> tun in this case) has the same attributes as the redirected device. Ie: if
> you open /dev/tun, the attributes of it are actually those of /dev/tun100.
> I dont think we can have a persistant /dev/tun that actually shows up on
> ls(1) etc, because we'd then have races with multiple processes scanning/
> accessing the directories or accessing and opening by different processes
> at once. Remember, the cloned device is different to every process.
> The whole permissions thing is a sticky one there.
I think my problem is that even though it's very sexy to be able to
clone devices on demand, there should be some way of determining in
advance (or of the sysadmin controlling) who can open these devices.
It's not easy to figure out what that means with cloning as it was,
but now that we can have a specific device name that can be used
again and again to get unique instances of the device, it seems clear
that that specific device name should appear up front and be
changable.
I expect to be able to
if (stat("/dev/tun", &st) == -1)
/* Clone device not supported - revert to old behaviour */
else {
printf("Opening %s\n", devname(st.st_dev, S_IFCHR));
fd = open("/dev/tun", O_RDWR);
fstat(fd, &st);
printf("Got %s\n", devname(st.st_dev, S_IFCHR));
}
and have output saying
Opening /dev/tun
Got /dev/tun100
I'm not sure that I see any races - vn_open could pass a vnode
pointer pointer into VOP_OPEN. Just before the devsw d_open is
called, some handler could be asked if it'd like to change the dev_t.
That handler can then make_dev(), returning the new dev_t, and d_open
is passed that. On the way back, a vnode is created for the new dev_t
and the vnode is passed back up into vn_open() which blindly continues
as normal.
ls -l sees /dev/tun which is make_dev()d in attach and destroy_dev()d
in detach, and may see other tun* devices if they've been make_dev()d
by this magic handler and haven't yet been destroy_dev()d by their
final close.
The Solaris (sysv?) way where a dev_t pointer is passed into d_open
and may be changed is probably better - that way the driver can never
be unsure about whether it's cloned a device that's about to be
opened or not.... it just needs to track which minors are open (in
fact, the infrastructure also does that for you in that you're
guaranteed not to be detach()d if there are outstanding opens).
> Cheers,
> -Peter
> --
> Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
> "All of this is for nothing if we don't go to the stars" - JMS/B5
--
Brian <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org>
<http://www.Awfulhak.org>; <brian@[uk.]OpenBSD.org>
Don't _EVER_ lose your sense of humour !
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105172003.f4HK3ib68172>