Standard sbc and pcm support in GENERIC kernel?

[Helge Oldach]

Mathew Kanner:
>On Mar 05, Helge Oldach wrote:
>> Daniel O'Connor:
>> >On Fri, 5 Mar 2004 19:06, Helge Oldach wrote:
>> >> The issue with kldloading is that you still need PNPBIOS for many
>> >> on-board sound devices. Which means that you need to compile your own
>> >> kernel anyway, or don?t you?
>> >
>> >I don't think I've ever seen a motherboard/BIOS where you HAD to
>> >compile it in the kernel..
>> 
>> I have a number of Compaq DeskPro EN K450 here. Rather decent machines
>> for FreeBSD desktops, and for sure not uncommon hardware. But
>> unfortunately the stupid Compaq BIOS doesn't have a knob to turn off
>> PnP, so I have to rely on PNPBIOS to deal with what the Compaq BIOS had
>> detected.
>
>	Are you required to compile sound in the kernel to get it to
>work?

Yes, that is exactly correct. I am sorry, I just wasn't clear enough
with my wording. To be safe, I just tested it:

case a) "options PNPBIOS" and "device pcm" in the kernel config => works

case b) "options PNPBIOS" in the kernel config and "kldload snd_pcm" =>
pcm isn't recognized, but the other PnP devices show up during probe

case c) *no* "options PNPBIOS" but "kldload snd_pcm" => neither pcm nor
other PnP devices are recognized

Did I forget one variation? :-)

>If so, then I will document the fact that in some unsual
>circumstances that including sound statcily in the kernel is needed,
>otherwise I intend to de-emphesize it.

I suppose the former is adequate.

What strikes me is case b). It seems a kldload'ed module cannot
recognize its devices when they were probed and attached by the PnP
BIOS. Does that sound reasonable?

This is 4.9-STABLE of some few days ago (right after the TCP re-assembly
queue fix). How will it work with -CURRENT which doesn't have a PNPBIOS
option? Can I use sound at all?

Helge