No, some of the naming issues can be handled with /proc/dev, but there
are a few problems:
- the "other" things about naming, not just the device number. That
includes owner and protection information (we do NOT want the kernel
to set policy), and the ability to map the devices to multiple
different names (/home/ftp/dev/xxxx).
- hardcoded device numbers: notably the root device
- NFS imported filesystems for machines
- system working without /proc
The /proc filesystem is not meant to be able to handle complexities like
this: it's meant to be a simple window to the kernel. It _looks_ trivial to
have the /proc filesystem have default protections for the files, and
then let the administrator override them with chmod/chown, but it gets
very non-trivial indeed when you want to mount the /proc filesystem on
multiple points on a machine at the same time (which _is_ possible, and
_should_ be possible).
There aren't that many hardcoded device numbers (I can't think of any but
the root device right now), so that should be reasonably easy to take
care of some way. So if that was the only problem I wouldn't worry.
The most important issue is probably that we do _not_ want to FORCE people to
use the /proc filesystem if they don't want to, and at boot-time, for
example, we want to be able to do basic housekeeping without /proc mounted
(and that definitely includes fsck'ing the root filesystem while it's
read-only mounted, and probably other disks too).
In general, I don't really like /proc/dev/ - it implies giving policy to the
kernel in one way or another (actual naming, permissions, placement, bootup
etc). Too much policy by far. We want to avoid policy decisions as far as
humanly possible.
Linus