Just thought I'd point out how powerful this concept is. The specific
example that's been thrown around is scanning for CDROM drives (I guess
because the cdparanoia author has talked extensively with Richard Gooch
about how useful such a thing would be). But the general idea is that we
provide a very useful and easy interface for an application to discover what
hardware is available in the system. Think about that for a second, because
I think it's a big mistake to dismiss it with "I don't think this is
useful".
The current system is easy for applications that have a specific piece of
hardware and try to use it (they either use it or get -ENOENT). Devfs works
just as well in that case (I guess it'd be -ENOENT instead of -ENODEV), but
it ALSO works for applications that want to dynamically discover the
supported hardware on the system. That's a whole new realm of uses of
application programs; one that isn't even very well developed because of the
difficulty of searching through /dev. And it's just one of the ways that
devfs makes life easier.
Chris
PS, yes it would be POSSIBLE to get this particular benefit of devfs by
implementing it via some other user-kernel communication mechanism. This,
IMHO, falls under Richards concept of "implement devfs but intentionally do
it in a way that's not as useful as devfs is". I would join Richard in
resenting a choice that prevents me from using information in such a
perfectly logical way. Fact is, of all the possible ways that the kernel
could communicate device information to user space, devfs is the most
useful.
-
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/