The basic problem is that when the kernel sees that it dosn't have the
driver for a device that somebody is trying to load, and it tells kerneld to
load "char-major-foo" or "block=major-foo". The problem is that, for sound,
different minors within the same major need different modules. There are
basicly two ways to solve this:
1) Change the protocol slightly to request "char-major-foo-minor-bar" (&
same for block); give kerneld the smarts to try "char-major-foo" if that
fails. (The elegant way, which I was going to work on a while ago.)
2) Add request_module calls in the sound drivers. (The ugly hack method.)
> > And possibly splitting sound & nfs to /lib/modules/'uname -r'/nfs and
> > .../sound?
>
> I know how to do this. I'm doing part of it in this patch. I might do
> all of it depending on how the puzzle pieces fit together. It requires
> one additional line in the top-level Makefile. Right now my patch
> touches files only in drivers/sound/* and there may be some reason to
> keep it that way.
I would go for it: I looked at it a while ago, and the top-level part is
trivial. It does mean that the sync between the voxware tree and the kernel
tree will drift further, but that process is already well underway.
> Personally I most like to work by putting patches up for ftp and
> gathering feedback over a period of time. Smart Config has gotten a lot
> better and more reliable this way. I hate it when people dump things
> into 2.1.XX and they've never been tested and they get patched and
> re-patched over the next several weeks.
True, but that way it does get tested. In any case, I think that Smart
Config is well ready for mainstream -- it has had plenty of testing, it
dosn't make dangerous changes. (I.E. it will work or it won't; it can't damage
data, or hardware, and it can't hang your system.)
> Also I need to spend some more time testing other people's patches,
> because so many people have spent time on mine.
(In the case of Smart Config, anyway), it takes negitive time to test your
patches: the time to dl and patch are FAR outwaighed by deceased make time.
A couple of suggustions:
1) Incremental patches, as well as from-offical patches. There is no
gaurantee that you can do smart-config, kernel upg., kernel upg.,
~smart-config, new smart-config safe/cleanly.
2) A combined patch (of all your makefile-related, up-to-date patches)
3) A works-with listing in your README.TXT; I assume that the version
numbers on the patches only get updated when the patch itself is.
-=- James Mastros
-- Information as a base of power is coming to an end. In the way the world works tomorrow, the power to *do* *something* *with* *information* is what will matter.-=- James Mastros, rephrasing Nugget (David McNett, distributed.net Big Man)