From owner-freebsd-arch@FreeBSD.ORG Sat Jun 11 18:56:59 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 35E8E106566C for ; Sat, 11 Jun 2011 18:56:59 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id B999C8FC12 for ; Sat, 11 Jun 2011 18:56:58 +0000 (UTC) Received: by wyf23 with SMTP id 23so3613650wyf.13 for ; Sat, 11 Jun 2011 11:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=xrrfAG0oq7bRRZ6uxMFClqEybLnAhiuMiCuwg7GlSB4=; b=KXSOsFCGqDjA1Sll3szP0Y5JGxOB59ESq6CLjJYDcTLRn401wK4le/1w2u6fjDsy/y 9M5fIb79v8YNNrm6YVVpVBhPgdVr9dMqiES30DDNG2vi6o9rG4Gx+Q55gbr4n7b/MyZH 2ku7oLF8+OscruJAGM17xiamq0OCqSigofAiA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=U3PsMF1sBIShCvMT9ZgvmmXQzjM0F+q6uj25bb5D2pQiFAqTpRf0MLfv51IiKS9cZx aH4AgFGN5H7nh1FMy6CvgJGC52l0FSjEmjgnl3pSqT/YqYfDudcuvwCVIuvYfvnPNFOD 34b9EpGDgJneA1QqM8Qt87yu0fuPBWWQfWWC8= MIME-Version: 1.0 Received: by 10.216.237.155 with SMTP id y27mr912935weq.82.1307817151977; Sat, 11 Jun 2011 11:32:31 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.216.52.141 with HTTP; Sat, 11 Jun 2011 11:32:31 -0700 (PDT) In-Reply-To: <20110611171834.GA38142@zim.MIT.EDU> References: <20110611171834.GA38142@zim.MIT.EDU> Date: Sat, 11 Jun 2011 11:32:31 -0700 X-Google-Sender-Auth: BYYvdrmyoQrZtlvvhYDpJsw_4es Message-ID: From: mdf@FreeBSD.org To: Adrian Chadd , freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 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 18:56:59 -0000 On Sat, Jun 11, 2011 at 10:18 AM, David Schultz wrote: > On Sat, Jun 11, 2011, Adrian Chadd wrote: >> Hi guys, >> >> Has there been any further thought as of late about shipping kernels >> with modules only by default, rather than monolithic kernels? >> >> I tried this experiment a couple years ago and besides a little >> trickery with ACPI module loading, it worked out fine. >> >> 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've been doing this for years, and it has come in quite handy. > For instance, when my if_msk gets wedged, the only way to fix it > short of rebooting seems to be reloading the driver. > > One issue, however, is that the boot loader is horrendously slow > at loading modules. =A0(Either that or my BIOS has a braindead int 13h > handler.) =A0Most of these modules aren't actually needed until much > later in the boot process, so a mechanism to load non-essential > modules after the file systems are mounted might provide a good > solution. Indeed, at $WORK we're trying to get shutdown -> restart under 2 minutes. Several seconds of this is moving things *into* the kernel that need to be there (disk drivers), and everything else to a point in init where modules can be loaded in parallel, using the faster disk driver, rather than in serial with slow BIOS handlers. I'm sure some things about our solution will be generally applicable, but I'm not sure there's a obvious answer that works for GENERIC. Any disk driver that could have a root filesystem under it needs to be in the kernel (or, more slowly loaded as a module by the loader). But then there's a need maybe for network drivers in GENERIC to support PXE boot? And as soon as modules aren't loaded by loader or part of kernel, parts of init will break and need fixing, since they previously relied on modules already being loaded... > OS X has an interesting solution, intended to preserve the > flexibility of dynamic modules, while minimizing boot time. > It provides a kextcache utility, which packages the kernel > and all of the needed modules into a single binary for better > locality on disk. =A0Unlike recompiling the kernel, running > kextcache is fast, and the system runs it automatically when > hardware or driver changes necessitate it. This would be interesting -- isn't it essentially a re-link of the kernel + modules? Cheers, matthew