> 1) Are the people working on the sound module aware of this,
Yes, painfully so. The modularization of lowlevel/ is quite broken.
> and what is the purpose of decomposing the sound modules below the card
> level ?
Multiple drivers share things like the uart401.o code. Thus it's natural
to make that a separate module for the sake of, well, modularity.
When I finish sorting out the CONFIG_* symbols then modprobe ought to
do the right thing for all drivers. The user or kerneld will load one
primary driver such as sb.o or mad16.o, and then modprobe will load the
necessary secondary drivers such as uart401.o and ad1848.o, plus the
base driver sound.o.
> 2) Are there any plans to enhance kerneld to support passing the major AND
> minor number to allow the degree of control now required (which would solve
> the problem very well) ?
I don't know; I don't even use kerneld.
> 3) If not, would you consider accepting patches to allow optional building
> of the old monolithic sound.o module to avoid these fun and games ?
Alan Cox is in charge, but I would not like such a patch. I would favor
backing all the way out to 2.1.76 but that question has been settled.
Here is the road map right now: Alan is making a pass through the code,
reformatting and cleaning up some things. Thomas Sailer is making lots
of memory-management changes. I have a patch in the wings to rewrite the
Makefile, Config.in, Defines, and local.h.master, also lowlevel/Makefile
and lowlevel/Config.in.
When all these things are in, the lowlevel drivers will probably still
have bugs, but they will at least be in hackable shape. Right now I
am not even looking at bug reports anywhere in drivers/sound until all
these changes go in.
Regards,
Michael Chastain
<mailto:mec@shout.net>
"love without fear"