From owner-freebsd-hackers Mon Oct 21 03:56:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA06457 for hackers-outgoing; Mon, 21 Oct 1996 03:56:10 -0700 (PDT) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id DAA06441 for ; Mon, 21 Oct 1996 03:56:04 -0700 (PDT) Received: from minnow.render.com (minnow.render.com [193.195.178.1]) by minnow.render.com (8.6.12/8.6.9) with SMTP id LAA04175; Mon, 21 Oct 1996 11:55:26 +0100 Date: Mon, 21 Oct 1996 11:55:25 +0100 (BST) From: Doug Rabson To: Julian Elischer cc: hackers@freebsd.org Subject: Re: DEVFS progress report In-Reply-To: <326A9F5D.2781E494@whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 20 Oct 1996, Julian Elischer wrote: > Well here's a progress report on devfs.. > > One of my original design goals was to do away with the > mechanism in the kernel known as "device vnode aliasing". > The theory was that if all references to the same device > ended up at the same vnode, then that would allow the vnode aliasing > code (messy stuff) to simply be elliminated. > Unfortunatly there is one problem about this that just cannot be > gotten around. If there is just one vnode for all instances for > a device, then all fstats on that vnode must return the same value. > no matter where it was openned from, even if the original > path looked as though it had a different set of attributes. > I've tried many ways to get around this but it's just too > hard to get "expected" unix semantics. The only way to achieve it > is to use a scheme that ends up looking exactly like > vnode aliasing, which is what I was trying to get away from in the > first place.. > > After trying for a year, I've basically decided that I can't > achieve this (laudable) goal. this has produced many complication > in the devfs design, and stopped me from doing many "obvious" > things. I will be changing devfs inthe near future to > re-allign it with the design now that I have removed that > one goal. hopefully this will allow the following to happen easier.. > > 1/ mounting root from the devfs (you'd be surprised how this is > affected) > 2/ translucent attribute storage > (I've been worrying how to do this.. this makes it more possible). > 3/ resolution of the problems with unmounting > filesystems mounted from devfs > 4/ assisting the ability to change permissions > for a device in one devfs without compromising another. (don't ask) > Are you going to be able to remove the dependancy on specfs? It seems to me that if you simply move spec_read/write/open/close etc. into devfs then you can avoid using [bc]devsw[] at all and call the driver directly through the pointers in the devnode. This would be a step forward IMHO since it would reduce the number of places which care about the major device number. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 FAX: +44 171 734 6426