From owner-freebsd-hackers Mon Sep 20 23:11:43 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 CBA5014BEC for ; Mon, 20 Sep 1999 23:11:36 -0700 (PDT) (envelope-from julian@whistle.com) Received: from home.elischer.org (home.elischer.org [207.76.204.203]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id XAA03637; Mon, 20 Sep 1999 23:11:23 -0700 (PDT) Date: Mon, 20 Sep 1999 23:11:26 -0700 (PDT) From: Julian Elischer X-Sender: julian@home.elischer.org To: John-Mark Gurney Cc: Brian Beattie , "Matthew N. Dodd" , Chuck Robey , Wayne Cuddy , FreeBSD Hackers List Subject: Re: what is devfs? In-Reply-To: <19990920190533.16613@hydrogen.fircrest.net> 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, 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