Date: Mon, 21 Oct 1996 11:55:25 +0100 (BST) From: Doug Rabson <dfr@render.com> To: Julian Elischer <julian@whistle.com> Cc: hackers@freebsd.org Subject: Re: DEVFS progress report Message-ID: <Pine.BSF.3.95.961021115111.14906J-100000@minnow.render.com> In-Reply-To: <326A9F5D.2781E494@whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.961021115111.14906J-100000>