Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 May 2001 12:19:22 -0700
From:      Peter Wemm <peter@wemm.org>
To:        Brian Somers <brian@Awfulhak.org>
Cc:        Poul-Henning Kamp <phk@critter.freebsd.dk>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/fs/devfs devfs_vnops.c 
Message-ID:  <20010517191922.B6C4D380A@overcee.netplex.com.au>
In-Reply-To: <200105171258.f4HCwKb63116@hak.lan.Awfulhak.org> 

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.

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


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?20010517191922.B6C4D380A>