On Sun, 10 Sep 2000, Christoph Hellwig wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > The enclosed patch corrects the Makefile and makes appropriate changes
> > to various doc files. Please consider accepting this for the next
> > kernel. This patch is against 2.4.0-test8.
>
> Aehmm. Your Makefile patch looks very strange:
>
> > -obj-$(CONFIG_SOUND_PAS) += pas2.o sb_lib.o uart401.o
> > +obj-$(CONFIG_SOUND_PAS) += pas2.o sb.o sb_lib.o uart401.o
>
> Why do you remove sb.o from the object list?
> The pas2 driver has no code to use the functions in sb_lib.o -
> It has only some code to enable the sb emulation of the pas2 card.
> Either you remove both sb.o and sb_lib.o and the pas2 sb emulation is gone,
> or you leave it as is. Alternative: you can add code to use the sb_lib.o
> stuff directly from the pas2 driver (this is the best solution, IMHO).
I know I misunderstand things occasionally, but it looks ok to
me. Isn't that just an artifact of the diff/patch thing? I simply
added sb.o to the line when I edited it. That's the way I've always
seen diff act. It deletes the original line and adds in an identical
line with what I added in. The second line above adds in an identical
line with sb.o added to the line.
> > - PAS16 compatible. Please read Documentation/sound/PAS16.
> > + PAS16 compatible. Do not enable both PAS16 support and Soundblaster
> > + support since PAS16 support includes support for Soundblaster.
> > + Please read Documentation/sound/PAS16.
>
> Why not - there shouldn't really be an issue with it.
> It builds fine for me (and the various distributions kernel rpms).
> And I doubt there is any runtime problem with that ...
No there isn't a runtime problem. Linus went through a phase recently
where he forced people to clean up "warnings" during the compile
stage. If you answer yes to both CONFIG_SOUND_PAS and CONFIG_SOUND_SB
you get "warinings" like this:
/mnt/hd/src/linux-2.3.99pre/Rules.make:267: target `uart401.o' given
more than once in the same rule.
My change eliminates that by eliminating the need to include both. It
also makes thing clearer IMHO.
> > - insmod opl3
> > + modprobe opl3
>
> either works well ...
Modprobe seems cleaner to me. It's an opinion and it's in my docfile so
I didn't see it as that big of a deal.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
