From owner-cvs-all Thu May 17 13: 3:56 2001 Delivered-To: cvs-all@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id ECFD337B423; Thu, 17 May 2001 13:03:46 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4HK3jP03974; Thu, 17 May 2001 21:03:45 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4HK3ib68172; Thu, 17 May 2001 21:03:44 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105172003.f4HK3ib68172@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Peter Wemm Cc: Brian Somers , Poul-Henning Kamp , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, brian@Awfulhak.org Subject: Re: cvs commit: src/sys/fs/devfs devfs_vnops.c In-Reply-To: Message from Peter Wemm of "Thu, 17 May 2001 12:19:22 PDT." <20010517191922.B6C4D380A@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 May 2001 21:03:44 +0100 From: Brian Somers 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. 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 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