[lkml]   [1999]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: UUIDs (and devfs and major/minor numbers)
On Wed, 16 Jun 1999 wrote:

> Explain to me how this is different from mounting devfs onto /kernel
> and using devfsd to populate a disc-based /dev.
> It isn't, as long as the names given by devfs are specific enough that a
> user-mode daemon knows what the device is. So if devfs is creating
> names like sda1, or c0t0d0s4, this isn't useful. Names like:
> /kernel/devices/pci/adapecc2980_0/... aren't something you'd *want* to
> appear in /dev, and indeed they don't appear in /dev under Solaris.
> They appear in /devices under Solaris. This is not an accident.

The Solaris /devices directory (Under Sparc at least) has much
nastier stuff than that. I agree the above, however, could be useful.
What about dynamic devices? I take it devfs would notify a daemon
that something new appeared in /devices, and then that daemon would go off
and create the /dev entry?
What about module loading by an attempt to access a particular
device under /dev? You might be able to simulate that by having symlinks
for any modules you have, but then, how do we know what modules you have?
Something in the kernel makefile to create the /dev entries? Yuck.
Perhaps the devfsd proggie could create them on boot from whatever is in
/lib/modules/`uname -r`/*? That might work, except you could end up with
lots of junk in /dev, much of it pointing to things that might not exist
in /kernel/devices. And might not be able to exist if someone compiles
modules for hardware s/he doesn't have.

> What makes you think the daemon should delete the device entry? I
> wouldn't. I would keep it there, since the device entry is cheap, and
> most of the time when a device is removed it's likely to come back
> later. In the rare case where hardware is being physically removed and
> it will never come back, the system administrator can simply delete the
> device for good later.

Now this sounds like you want /kernel/devices to be a filesystem
somehow, and to not be virtual. Unless of course symlinks can have
permissions... Or you have something like what devfsd does w/ tar for
I don't THINK Solaris even does this (I try to avoid playing in
/devices too much). IIRC, if you remove something out of the system, the
entry in /devices goes away, but the symlink persists, and if the identical
device is put back in the system in the same place, the /devices entry
comes back, and as such the /dev symlink becomes operational again.
This doesn't keep permissions around, at least, I don't think so,
I could be wrong on this.

> Again I'll ask the question I've already asked a number of times. How
> would you cleanly support a construct like this:
> opendir ("/dev/ide/cd");
> loop;
> 1) I don't think this is useful.
> 2) Even if it is useful, it shouldn't be done via /dev. Via /proc, or
> the hypothetical /kernel/devices interfaces, perhaps, but not /dev.

There have been folks asking for it. So you'd have a
/kernel/devices/cd file(?) that has a list of the /dev entries for all
the devices on the system? Or have it be a directory w/ symlinks to /dev,
which are symlinks back into /kernel/devices? I would think someone
looking for CD drives would want to open the 'proper' device under /dev.
Though, this could all be handled in user-space, and could be
configured by a user.
mkdir /dev/cd; ln -s /kernel/devices/ide0/slave /dev/cd/ide_cd1
But then, programs couldn't depend on it...


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:52    [W:0.105 / U:1.428 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site