Theodore Y. Ts'o writes:
> My big complaint with the devfs idea is that it's putting a huge
> amount of policy and configuration issues into the kernel, when you
> can do nearly all of it outside of the kernel, in user space.
> Having a daemon which ran at initialization time and initialized
> /dev would be far more preferable, in my view. Furthermore, in the
> case of disks, if you are going to be doing this kind of mapping, it
> should be reading the filesystem labels and then creating devices
> which map at the filesystem label. This way, if people move SCSI
> ID's around, or even add and remove SCSI controllers, it won't
> matter, since the mount devices in /etc/fstab would be defined in
> terms of volume labels in the ISO9660 or ext2fs superblock. I've
> been working on a counterproposal in my spare time, but I've
> unfortunately been a little too busy. If there's someone who's
> interested in helping work on a counterproposal to devfs, let me
> know....
It's not just about discs, you know, although it provides a nice
solution for that. It's also about keeping a tidy /dev.
But perhaps most importantly, it fixes something that I consider a
real flaw in Unix: the duplication (and subsequent need to
synchronise) of the database of device numbers. While
Documentation/devices.tex is supposed to be the master list, the
reality is that the kernel sources maintain one list (scattered
throughout many files) and MAKEDEV, MAKEDEV-C and every /dev on the
planet maintain their own lists. The duplication of this information
leads to mistakes and the need for people to put effort into
synchronising. That worries me.
BTW: I actually *like* the idea of mounting via volume labels! I think
it is a good solution for really big systems. However, I also think
using logical names has it merits. I don't see this as an either/or
situation. Volume-based mounting is *not* an alternative to devfs
because devfs isn't just about different device names. Every time this
discussion comes up this point seems to get missed.
Also, your idea of having a daemon that populates /dev is not a good
idea, IMHO, because:
1) it would be slow
2) it would require a patch that is essentially the devfs patch minus
the ability to mount a FS (the device information still needs to
be recorded in a database, devfs includes the ability to access
that database via a FS).
I'll also point out that for those who really can't accept mounting
devfs on their system and would prefer your daemon idea could easily
use devfs to provide the information (i.e. access its database) to the
daemon which then populates /dev. People who want to slow down their
machines will have that option.
Please also consider that this "policy" you are concerned with is not
really a problem. You aren't compelled to use the names and
protections provided if you don't want to. It just provides convenient
access to a default.
BTW: I wouldn't argue too strongly against policy, either. When I see
Red Hat system which don't follow Documentation/devices.tex, I
sometimes think that a bit of discipline^H^H^H^H^H^H^H^H^H^Hpolicy
might be in order. Deviating from Documentation/devices.tex seems like
a good way to break userspace.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
