Messages in this thread | | | Date | Thu, 17 Jun 1999 11:31:02 -0400 (EDT) | From | Stephen Frost <> | Subject | Re: UUIDs (and devfs and major/minor numbers) |
| |
On Wed, 16 Jun 1999 tytso@mit.edu 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 /kernel/devices. 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...
Stephen
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |