Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 11 Jun 2011 21:22:45 +0800
From:      Adrian Chadd <adrian@freebsd.org>
To:        Robert Watson <rwatson@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:  <BANLkTik%2B-gVXGQkFmTH%2Bm2hswfnrRcawrg@mail.gmail.com>
In-Reply-To: <alpine.BSF.2.00.1106111403060.44950@fledge.watson.org>
References:  <201106110908.p5B98kkE066709@svn.freebsd.org> <alpine.BSF.2.00.1106111403060.44950@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
btw, I just posted something similar to this on -arch.


adrian

On 11 June 2011 21:07, Robert Watson <rwatson@freebsd.org> wrote:

> To me, this seems like the wrong direction. =A0Over the last decade, we'v=
e
> been trying to move away from conditional compilation of features to havi=
ng
> them be loadable as modules. =A0The arrival of freebsd-update has only
> increased the pressure to take this approach: we want to avoid the need t=
o
> customise kernel configurations as much as possible, so that users get
> binary updates in the common case. =A0As sound already fully supported be=
ing
> 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). =A0Wha=
t we
> need to supplement that is a way to detect that modules *should* be loade=
d
> based on PCI IDs or similar, which could then trigger loading of the soun=
d
> drivers, and other similar supplementary modules.
>
> While it seems like memory is "free" these days, that's not really the ca=
se.
> 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTik%2B-gVXGQkFmTH%2Bm2hswfnrRcawrg>