Date: Sat, 11 Jun 2011 14:47:49 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Adrian Chadd <adrian@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Joel Dahl <joel@freebsd.org> Subject: Re: svn commit: r222980 - in head/sys: amd64/conf i386/conf Message-ID: <alpine.BSF.2.00.1106111445460.44950@fledge.watson.org> In-Reply-To: <BANLkTik%2B-gVXGQkFmTH%2Bm2hswfnrRcawrg@mail.gmail.com> References: <201106110908.p5B98kkE066709@svn.freebsd.org> <alpine.BSF.2.00.1106111403060.44950@fledge.watson.org> <BANLkTik%2B-gVXGQkFmTH%2Bm2hswfnrRcawrg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-730146219-1307800069=:44950 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT 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 <rwatson@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. > --621616949-730146219-1307800069=:44950--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1106111445460.44950>