Not if Major/minors can be assigned dynamically... If the boot process
needs the daemon before it can determine the major/minor numbers there
will be other problems too, especially in small recovery systems being
used to rebuild root disks or installation boot.
> - Kernel modifications are minimal (changes to init/cleanup_module).
>
> - Major/minors can be assigned dynamically by drivers, avoids GUID.
>
> - Topology rules for USB can be over-engineered totally in user space.
>
> - The policy for naming nodes moves to user space, hpa is happy.
>
> - Persistence of nodes is maintained by the filesystem, tso is happy.
>
> - Devfs gets into the kernel, everyone else in the world is happy.
I have used a devfs structure - IRIX uses it. I've seen some of the
problems (I wish they would use slot identity more). Presistance of
ownership is not perfect. Until ownership of a device is moded into
the device itself (rather than on a disk inode) it will not be possible
to allocate/reserve devices. Some form of permanence is needed. But until
device allocation is possible, I would prefer the root account to own
all devices, with little/no user access until they are allocated. If I
need to always set certain devices to other permissions, then I am willing
to setup a boot script that sets them (the script would be driven from
a configuration file containing owner, and modes, and device to set).
I would like ACLs too (the world next..oh well..) which push for a disk
resident portion, but if the /dev directory tree has to be rebuilt each
time the system boots, then I will setup a boot script to set them. I
don't really care whether a memory resident /devfs is done or not - I don't
expect either will be a final solution. If /devfs fixes/improves two out of
three things then I would tend to use a /devfs. Having to depend on a daemon
to rebuild /dev to get it to match the real hardware doesn't seem to be
reliable since the major/minor numbers are needed to access the root system.
If the root moves, then the daemon must also be running before any devices
are mounted. /devfs appears to fix this, since the kernel is actually building
devfs during device initialization (major/minor numbers can be dynamically
assigned).
Also not listed among the difficulties is identifying which device (physical)
is associated with which major/minor number. Right now I look at /proc/pci
which shows the devices, but doesn't associate the major/minor number. I have
to assume that the first SCSI controller is sd ( but then they all are..)
and the first disk listed on the complete list (all controllers) is sda.
This works until removable (USB or some SCSI) devices are included. At this
point all bets are off. Just because a USB zip drive was removed (say out of
a chain of 3) why should the remaining devices get new major/minor numbers
after a boot? why get renamed? they have a fixed address - it's just lost
in the conversion. This looks like an insufficient mapping of the hardware
configuration. I like the idea of pci/slot/controller/unit/lun/slice
structure that can provide a fixed address that mapps to just about
anything. Yes it can get long, but the names stay the same, the major/minor
numbers become more irrelevent, and I can be more certain about which device
is what. This can give fine graned control over access (ownership/acls/modes).
I hope this isn't too much of a rant - some of these problems have been
brought up before
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
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/