Date: Mon, 20 Sep 1999 18:52:28 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Brian Beattie <beattie@aracnet.com> Cc: John-Mark Gurney <gurney_j@resnet.uoregon.edu>, "Matthew N. Dodd" <winter@jurai.net>, Chuck Robey <chuckr@mat.net>, Wayne Cuddy <wayne@crb-web.com>, FreeBSD Hackers List <freebsd-hackers@FreeBSD.ORG> Subject: Re: what is devfs? Message-ID: <Pine.BSF.3.95.990920182431.6478K-100000@current1.whistle.com> In-Reply-To: <Pine.LNX.4.10.9909201801520.19794-100000@shell2.aracnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <script that chmods every device to it's present modes/owner> > > Brian Beattie | The only problem with > beattie@aracnet.com | winning the rat race ... > www.aracnet.com/~beattie | in the end you're still a rat > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.990920182431.6478K-100000>