From owner-freebsd-hackers Sun Oct 20 14:58:30 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA18418 for hackers-outgoing; Sun, 20 Oct 1996 14:58:30 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA18378 for ; Sun, 20 Oct 1996 14:58:11 -0700 (PDT) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.7.6/8.7.3) with SMTP id OAA12318 for ; Sun, 20 Oct 1996 14:55:49 -0700 (PDT) Message-ID: <326A9F5D.2781E494@whistle.com> Date: Sun, 20 Oct 1996 14:53:33 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: DEVFS progress report Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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) I hope you will all bear with me as I make these changes. (or is that "bare"?) julian