Am Freitag, den 10.02.2006, 16:06 -0500 schrieb Bill Davidsen:
> The kernel could provide a list of devices by category. It doesn't have
> to name them, run scripts, give descriptions, or paint them blue. Just a
> list of all block devices, tapes, by major/minor and category (ie.
> block, optical, floppy) would give the application layer a chance to do
> it's own interpretation.
Introducing more than interface for doing the same thing can be very
confusing and counter-productive. You'll create new, undocumented or
semi-documented interfaces which will lead to a dependency chaos.
Some random script will work with kernel 2.6.11, 2.6.12 and 2.6.13, but
not 2.6.14 and later because a new device class was introduced and two
typos were fixed. Especially considering that the new linux development
model makes it likely that major changes go into micro releases,
stability and reliability will be a huge problem.
> HAL is great, but because it's not part of the
> kernel it's also going to suffer from "tracking error" for some changes.
> I find it easier to teach someone to use -scanbus than to explain how to
> make rules for udev.
Tastes are different. I think the HAL semantics are perfectly OK for
doing what you want, i.e. you can use hal-find-by-capability together
with hal-get-property to get the block device paths of the installed
mass storage and for distinguishing them.
Distributors should ship sane udev rules applicable for 99.5% of the
people out there. They do, actually.
> > [...]
> Worth repeating: I find it easier to teach someone to use -scanbus than
> to explain how to make rules for udev.
> HAL is the right answer,
Nice that we agree on that.
> but *in* the kernel, where it will track changes.
Oh, and BSDs and other target systems of interest for higher-level
libraries and applications don't need libhal? What do we gain by pushing
more and more functionality down the stack right into the kernel,
without guaranteeing ABI/API stability? HAL was developed with
portability in mind, why should one give it up for solving hypothetical
problems, depending on release cycles and patch review by external
projects? I thought the original plan was rather to break the kernel
down and not to make it a melting pot for all kinds of specialized
functionality, which to my impression was originally done because of the
lack of vendor support.
> Since -scanbus tells you a
> device is a CDrecorder, or something else, *any user* is likely to be
> able to tell it from DCD, CD-ROM, etc. Nice like of text for most devices...
Well, "any user" just opens his Windows Explorer and takes a look at the
icon of his drive D:\\ to see whether it's a CD-ROM or DVD. It is
interesting to see professional programmers often argue that a
particular solution they like is appropriate for all users without
giving proof. I can't think of a single reason why a user wants to dump
all his devices without knowing the grep semantics, which in turn makes
it very likely that he will write some wrapper code around any of the
currently perfectly working solutions.
--
Christian Neumair <[email protected]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
