Date: Sat, 11 Jun 2011 14:07:17 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Joel Dahl <joel@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r222980 - in head/sys: amd64/conf i386/conf Message-ID: <alpine.BSF.2.00.1106111403060.44950@fledge.watson.org> In-Reply-To: <201106110908.p5B98kkE066709@svn.freebsd.org> References: <201106110908.p5B98kkE066709@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1106111403060.44950>