From owner-freebsd-hackers Mon Sep 20 18:52:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 54A7A15B4C for ; Mon, 20 Sep 1999 18:52:36 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id SAA95017; Mon, 20 Sep 1999 18:52:29 -0700 (PDT) Date: Mon, 20 Sep 1999 18:52:28 -0700 (PDT) From: Julian Elischer Reply-To: Julian Elischer To: Brian Beattie Cc: John-Mark Gurney , "Matthew N. Dodd" , Chuck Robey , Wayne Cuddy , FreeBSD Hackers List Subject: Re: what is devfs? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 20 Sep 1999, Brian Beattie wrote: > On Mon, 20 Sep 1999, Julian Elischer wrote: > > > > > > > > > While I sharply disagree, with your assertion, I also point out that if > > you make such a all-singing-all-dancing devfsd, then you might as well get > > rid of devfs entirely, and just have devfsd make the devices using normal > > mknod commands. > > > Since I did not follow the original discussion, maybe this idea has been > discussed and discarded, but what about a "translucent" like deal. > Basically yu would mount the devfs on top of an existing directrory or > filesystem. The underlying contents would "show through" by some set of > rules. One rule would be that if a device node existed in the devfs and > the real fs, and the device node in the real fs was for the "fake/null > whatever you want to call it device", the resulting device node would have > the major/minor fron the devfs and the owner/group/permissions from the > real fs underneath. Any change to the node would affect the real fs > underneath. I could probably expand on this futher if anybody is > interested. Basically this is my scheme. Using something like a 'union mount'. I expounded tis as a possibility a few years ago. It is about as close as I can get using a filesystem to do the work. A daemon can do these things easily but has other drawbacks. ----- the rules are: When mounted with option -layer.. Underlying files do not show through unless the upper one exists. Underlying files supply their ownership/perms but get the major/minor from the devfs layer. The underlying files would be empty regular files (i.e. just an inode). Devfs devices that have no underlying node get their default permissions. Chmod/chown operations create an empty underlying node (if it can, and if the perms change from the default) to hold that info. If mount option -nonew is used only items present at mount time are automatically reflected through. mknod can be used to create new ones but the major an minor will be taken from the devfs blueprint, If the device is not in the devfs the mknod fails. If mount option -empty is used then an empty devfs is mounted. All devices must be created as above. if mount option -clear is used (with -u) then the underlying nodes are all removed. (garbage collection). When the underlying nodes are removed, the upper node still keeps the existing permissions. The action of mv'ing a device doesn't change the name of the underlying node it's associated with.. (it remembers). (and the info) ------ to snapshot /dev's permissions and clean all junk underlying files.... mount -u -clear /dev