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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
