svn commit: r222980 - in head/sys: amd64/conf i386/conf

[Robert Watson]

On Sat, 11 Jun 2011, Joel Dahl wrote:

> Log:
>  Enable sound support by default on i386 and amd64.
>
>  The generic sound driver has been added, along with enough
>  device-specific drivers to support the most common audio
>  chipsets.
>
>  We've discussed enabling it from time to time over the years
>  and we've received numerous requests from users, so we decided
>  that shipping 9.0 with working audio by default would be the
>  best thing to do.
>
>  Bug reports should be sent to the multimedia@ mailing list, as
>  usual.

To me, this seems like the wrong direction.  Over the last decade, we've been 
trying to move away from conditional compilation of features to having them be 
loadable as modules.  The arrival of freebsd-update has only increased the 
pressure to take this approach: we want to avoid the need to customise kernel 
configurations as much as possible, so that users get binary updates in the 
common case.  As sound already fully supported being loaded as a module, and 
isn't needed to boot the system, it seems unfortunate that we'd move from 
loading it as a module to compiling it in.

It seems like what we almost want is a default set of modules for loader.conf, 
which are automatically loaded (but not compiled in).  What we need to 
supplement that is a way to detect that modules *should* be loaded based on 
PCI IDs or similar, which could then trigger loading of the sound drivers, and 
other similar supplementary modules.

While it seems like memory is "free" these days, that's not really the case. 
The base kernel footprint is quite observable in VM configurations, where it's 
common to configure quite low memory footprints -- 256M, 512M, etc, in order 
to improve VM density.

It would be great if devd could subsume unmatched PCI ID attachment and 
reference a database of device drivers to figure out what to load.

Robert