On Sat, 11 Jun 2011, Adrian Chadd wrote:
btw, I just posted something similar to this on -arch.
FWIW, it doesn't have to be pretty, it really just has to work. It would be
nice if the same data could be used by both the boot loader and devd to load
driver modules, and if the data were structured so that it could be easily
extended. I.e., /etc/driverdb with individual .xml or .whatever files, one
per device driver, laying claim to things. That way if there's going to be
duking out for ownership of the device during early device, it's all worked
out then.
Anyhow, I don't have really strong opinions on how it's done, except that it
needs to be. And ideally soon :-).
Robert
adrian
On 11 June 2011 21:07, Robert Watson <rwat...@freebsd.org> wrote:
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.
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
