From owner-cvs-all Thu May 17 12:19:31 2001 Delivered-To: cvs-all@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 181EF37B422; Thu, 17 May 2001 12:19:23 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f4HJJMM60899; Thu, 17 May 2001 12:19:22 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id B6C4D380A; Thu, 17 May 2001 12:19:22 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Brian Somers Cc: Poul-Henning Kamp , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/fs/devfs devfs_vnops.c In-Reply-To: <200105171258.f4HCwKb63116@hak.lan.Awfulhak.org> Date: Thu, 17 May 2001 12:19:22 -0700 From: Peter Wemm Message-Id: <20010517191922.B6C4D380A@overcee.netplex.com.au> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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