> Look to devfs as a way of cleaning up procfs instead. Move all the
> non-process stuff into devfs. That way we can get back to a procfs the
> way it was intended.
>
> Well, no, that doesn't work, since there plenty of non-process stuff
> which doesn't fit into a devfs mounted in /dev.
Such as?
/proc/net, /proc/sys, and /proc/fs definitely doesn't belong in /dev. I
would think that's pretty self-evident.
> Now, if you were to make an argument for a /kern that had the
> non-related process stuff, and perhaps one of the things in /kern
> was something like was is in Solaris's /devices directory, that
> might be interesting. What Solaris has in /devices are names which
> are designed to be unique and explicit about what they are attached
> to. For example, we might have a device name vaguely like:
>
> /kernel/devices/pci/adaptec2980_0/id0/lun0/part1
>
> ...and then having a user-mode daemon make symlinks from /dev/sda1,
> or /dev/disks/<fslabel>, or /dev/scsi/disks/*, or whatever new
> experimental naming scheme that people want to experiment with.
> That's definitely policy that shouldn't be enforced by the kernel,
> so we would have a user-mode daemon that can consult a database (ala
> lspci, etc.) which can be changed when people want to experiment
> with different structures and hierarchies in /dev. This may or may
> not be the best approach, but I believe it's better than the current
> devfs approach.
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.
But this is a straw-man argument, because it ignores the persistence
problem with a dynamic disc-based /dev which is managed with a user
space daemon. This is a problem that's been overlooked.
Consider what happens if your daemon creates and deletes device
entries based on information from the kernel as to what devices are
installed (and drivers loaded). When a new device is plugged in, *what
permissions should be given*? OK, say you get some default. So the
sysadmin does chmod(1) to change this.
What happens if a device is removed? The daemon deletes the device
entry. Then the device is plugged back in again. *What permissions
will be given*?
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.
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.
Except that devfs isn't a mistake. It's the Right Thing[tm].
That's you're opinion; it's not mine.
- Ted
-
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/