From owner-freebsd-arch@FreeBSD.ORG Sat Jun 11 16:59:58 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B7261065672; Sat, 11 Jun 2011 16:59:58 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 9EDE38FC0C; Sat, 11 Jun 2011 16:59:57 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p5BGsxRn055543 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 11 Jun 2011 10:55:02 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sat, 11 Jun 2011 10:54:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <64005736-63ED-47DB-82BD-964F237AD933@bsdimp.com> References: <20110611104355.GH48734@deviant.kiev.zoral.com.ua> To: Adrian Chadd X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 11 Jun 2011 10:55:02 -0600 (MDT) Cc: Kostik Belousov , freebsd-arch@freebsd.org Subject: Re: [RFC] shipping kernels with default modules? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 16:59:58 -0000 On Jun 11, 2011, at 7:21 AM, Adrian Chadd wrote: > On 11 June 2011 18:43, Kostik Belousov 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=