Date: Sat, 11 Jun 2011 10:54:52 -0600 From: Warner Losh <imp@bsdimp.com> To: Adrian Chadd <adrian@freebsd.org> Cc: Kostik Belousov <kostikbel@gmail.com>, freebsd-arch@freebsd.org Subject: Re: [RFC] shipping kernels with default modules? Message-ID: <64005736-63ED-47DB-82BD-964F237AD933@bsdimp.com> In-Reply-To: <BANLkTi=_ByLY9BZs92Uf4e%2BidKkDx-LbCw@mail.gmail.com> References: <BANLkTin2AwKRT7N6HWqBctJcT72_mR=Otg@mail.gmail.com> <20110611104355.GH48734@deviant.kiev.zoral.com.ua> <BANLkTi=_ByLY9BZs92Uf4e%2BidKkDx-LbCw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 11, 2011, at 7:21 AM, Adrian Chadd wrote: > On 11 June 2011 18:43, Kostik Belousov <kostikbel@gmail.com> wrote: >>> Is there any reason we aren't doing this at the moment? Eg by having = a >>> default loader modules list populated from the kernel config file? >> I use highly modularized kernel on all machines, because it allows me >> to use (almost) the same kernel config. >>=20 >> Will you provide a prototype change for your suggestion ? >=20 > Sure, but in a couple weeks, or when I decide next to avoid study and > need a break from if_ath hackery, whichever comes first. For 9, I'd suggest compiling MINIMAL config file that takes everything = out of GENERIC that can be a module. This would be the install kernel. = We'd create a loader.conf that lists everything currently in GENERIC. = This would give us most of the benefits and allow our users to edit = loader.conf to include the minimal set. For 10, I'd suggest that we'd standardize the driver data such that we = can determine from the plug and play strings what to load. This should = be done with devd, not the boot loader. The boot loader would need to = load all device's necessary to get / mounted. Robert suggested having an /etc/driverdb file. Unless that file is = automatically generated, it will be stale all the time. One last thing to note is that we'd only need to know which modules to = load from the plug and play strings. There's a few instances in the = tree where from the plug and play strings we'd need to load two = different modules (look at the re/rl attach routines for one instance of = why). Oh, the other last thing to consider is that the module system doesn't = have any notion of drivers that are attached (or even bound to device = nodes unattached). If we had some notion, it would be easier to = automatically unload the unnecessary drivers. Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?64005736-63ED-47DB-82BD-964F237AD933>