Date: Mon, 20 Sep 1999 23:11:26 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: Brian Beattie <beattie@aracnet.com>, "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.4.05.9909202307040.22714-100000@home.elischer.org> In-Reply-To: <19990920190533.16613@hydrogen.fircrest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Sep 1999, John-Mark Gurney wrote: > Julian Elischer scribbled this message on Sep 20: > > 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. > > what happens in this case: > mount /devfs > cd /devfs > mv ttyd1 da0c # sure you don't normally do this but you CAN! da0c is now the name of the vissible alias of ttyd1 > cd / > umount /devfs > mount /devfs ttyd1 is now the name of the visible alias of the device. > > sorry, that doesn't cut it as you loose your "dynamic" links from the > umount to mount, and we are back to the major/minor number to keep > track of which device node belongs to which device... no the "original" name is tracked. I don't see your problem the device reverts to it;s original name as it should.... it remembers any permissions it was given under either name... I think this is good. you may think it's bad. why? 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.4.05.9909202307040.22714-100000>