IMHO you are missing the other features of devfs. Since you agree that there
needs to be kernel support anyway for a devfsd (name to be understood
generic), why not go for the whole thing ?
Since we can agree, I hope, that the present system is unworkable (drive
letters in principle, like DOS). We must look at the alternatives.
1. Simply enlarge major:minor to 32:32.
There is no support for a devfsd, so no hotplugging.
2. Enlarge major:minor to 32:32 and add support for a devfsd (likely
modelled after PCMCIA)
a)If we wish to have persistent device names, we need to have an awful
number of devices, which would have to be created automatically and
dynamically. So you would have to base permissions on some rules used by
devfsd. So you would like your permissions to be non-persistent, if you had
the choice. (reboot with different devices and devfsd fails, you have device
files with wrong permissions hanging around).
b)No way of loading drivers on access to a device name. This is necessary
for ,e.g. an external scsi-tape switched on after boot.
3. Use devfs
Devfs will get you all that and more
On policy in the kernel:
It is hard not to put policy in the kernel, and the existing policy is just
overlooked, because it is so ancient.
1. Names in the kernel.
Either the kernel exports names or numbers, if you wish other names it is
either symlinks or names for device nodes. In addition there are names in
the boot code and error messages.
2. Default permissions.
With devfs default permissions are set by the driver to a sensible value or
set by devfsd. Without devfs it is practically root.root 000 (no device
node)
Persistance of permissions:
Traditionally permissions are stored in the device nodes. This is said to be
benefitial to security. However you have permissions like root.uucp 660 on a
device and membership to uucp is controlled by a config file, or root.disk
660 and who may mount controlled by another config file. IMHO there is no
additional risk in having permissions based on /etc/devfsd.conf. I am sure
chmod and chown on a file in a devfs can be tra<pped and reported to devsfd.
This is somewhat complicated, but secures full backward compatibility.
Devfs may break some ancient unix traditions, but it solves the problems at
hand and is quite well tested.
Look at it another way. Suppose I'd suggest adding two file types just to
store permissions ;-)
Regards
Oliver
-
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/