> 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 muchnastier 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 offand 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 filesystemsomehow, and to not be virtual. Unless of course symlinks can havepermissions... 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, theentry in /devices goes away, but the symlink persists, and if the identicaldevice is put back in the system in the same place, the /devices entrycomes 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 allthe devices on the system? Or have it be a directory w/ symlinks to /dev,which are symlinks back into /kernel/devices? I would think someonelooking for CD drives would want to open the 'proper' device under /dev. Though, this could all be handled in user-space, and could beconfigured 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" inthe body of a message to majordomo@vger.rutgers.eduPlease read the FAQ at http://www.tux.org/lkml/