Here's one that's had me puzzled for a long, long time,
the original old chestnut if you like...
As far as I can make out, the Unix, and Linux philosophy
in the area of device drivers, is to simply provide a
software interface to the hardware in question. This is
substantiated by inspection; the device driver generally
supports data transfer to and from the hardware via
read() and write(), and software hooks to change the
state of said hardware via ioctl().
Now, the level of abstraction _from_ the hardware is
quite minimal; abstraction, and device independance,
is provided with libraries. Libraries can have members
which provide a common software interface for hardware
which may well be dissimilar in implimentation, but
similar in function.
Obviously, if my understanding is incomplete, inaccurate,
or just plain wrong, then the remainder of this post will
be rendered nonsensical; still, I would like to hear about
it, I do want to learn...
Ok, question time, class; Why does Linux's sound driver
seek to encapsulate *all* possible sound hardware in one
In my quite possibly ill-informed opinion, Linux _should_
have device driver support for given sound hardware
implemenations, sure - that's what device drivers seem to
be all about. But surely, bundling all sound devices into
one common model, that of dsp, mixer, and sequencer, is
a job for a sound library?
Cheers, I'd really like to see this one thrashed out,
if only for my personal education.
strength through elegance /// beauty in intelligence