Sure - with the proposed 32-bit device numbers.
>True. Use rm(1)
Not creating offending nodes in the first place is even better.
> I'm not arguing against devfs, I'm arguing against the idea that a dynamic
> naming scheme for devices will magically manage your devices for you. It
> just can't.
>
> for i in 0 1 2 3 4 5; do
> MAKEDEV usb$i
> done
>
> is so hard that the kernel _must_ do it for you?
That would be convenient - yes.
It don't have to be the kernel itself - a daemon is good enough.
How about something like this:
Use the current system with major/minor numbers, possibly with more
bits.
Any device driver that auto-detects a device (boot time or later)
call a daemon, informing it of major/minor numbers and a suggested
device name and default permissions.
The daemon checks if the device node exist already. If it doesn't
it is created, with the suggested name and default permissions.
No problem if the daemon dies somehow. We will be no worse off than
today. It will be uncommon though.
We don't need to upgrade all device drivers at once. Devices
who don't call the daemon will simply rely on someone else running
mknod.
Persistence works the way it does today. An ext2 crash deleting
stuff in /dev is a smaller problem, as the nodes will be recreated
at the next device initialization.
The check for existing nodes is up to the daemon makers. It could be
as simple as looking up the suggested name in /dev, or it could
be a search through /dev (or some other configured place) to see
if a node with the given device number exists. The latter approach
will catch the case where the user wants to rename devices.
Those who don't want a time consuming directory search whenever devices
initialize can use the simpler daemon.
Distributions could start with an almost empty /dev and have the
kernel+daemon fill it up with existing stuff. Only people doing
lots of hardware testing will ever need to clean up.
Helge Hafting
-
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/