I too view this as the big win in the /devfs strategy. I can state
for absolute certain that users *are* constantly confused by keeping
the kernel and /dev in sync. I get alot of "help me!" mail along
those lines from users trying to set up generic SCSI support for use
with cdparanoia (usually saying "hey! Your program is broken!")
>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.
How is it configurable? I actually *like* the idea of a /dev naming
policy, although I also admit that this is only because it serves my
needs (I have to automatically find various sorts of hardware on a
system. Having /dev entries where I expect them to be seriously
expedites this process). I do want to ask Ted (he would not have
mentioned it unless he had examples in mind) of what sort of thing
this enforced policy breaks?
>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.
"Bing bing bing" The man wins a prize. :-)
All that said, I'd still like to get more comments from Richard et-al
about the "guessing game" problen that devfs creates. I *don't* know
beforehand what my devices will be named-- I don't even know that
they're there. Paranoia currently does a long, complicated dance with
the kernel involving /proc/devices, dev directory entries, peeking at
the modules compiled into /lib/modules and so on to figure out what
hardware is on the system without hosing the thing into the ground
(and potentially crashing it if, for example, the Aztech proprietary
CD driver tries to load without an Aztech CDROM drive actually being
there... its autoprobe is carnivorous).
The whole reason I don't like Joerg's bus:target:lun addressing scheme
is that I can't go to the hardware that I want; I have to probe,
probe, probe until I get lucky or decide to give up. (How many
devices/chains could the machine possibly have? Where do you stop
looking? SnotFish, my new test box for Paranoia, fills seven chains
with devices). Devfs now introduces exactly the same problem as
Joerg's SCG. I can't just say "what are the cdrom drives on my
system?" without hitting every damed SCSI, parallel port, and IDE-like
device on the box.
OTOH, it would be soooooo easy (believe me I am *drooling* here) if I
could CD to /dev/sr and see all the CDROM drives on all my SCSI chains
there indexed by BTL. Then I could go into /dev/sg and see everything
there by BTL too. Easy direct matching. This doesn't address IDE
naming and so on (A note to the IDE driver authors-- why does the
driver hide device type from userspace? Annoying!), but just cutting
down endless SCSI probing is a big chunk of the battle.
This may be looking at the technical problem the wrong way, but
seriously consider: what would it take to be able to populate /devfs
accurately and completely from bootup? Without the device information
always being there (/proc won't help either if the module isn't
loaded), the greatest benefit of /devfs isn't realized: A centralized,
accurate, consistent database of devices on the machine. Without it,
you've solved the duplication problem but at the expense of making the
interface *much* harder to use (and program to).
Monty
-
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/