From owner-freebsd-stable@FreeBSD.ORG Fri Jan 6 20:31:23 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74ACA16A41F; Fri, 6 Jan 2006 20:31:23 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail24.syd.optusnet.com.au (mail24.syd.optusnet.com.au [211.29.133.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id B98BB43D46; Fri, 6 Jan 2006 20:31:22 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail24.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k06KVKCQ001186 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 7 Jan 2006 07:31:21 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id k06KVKHh055483; Sat, 7 Jan 2006 07:31:20 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id k06KVKvY055482; Sat, 7 Jan 2006 07:31:20 +1100 (EST) (envelope-from pjeremy) Date: Sat, 7 Jan 2006 07:31:20 +1100 From: Peter Jeremy To: freebsd-stable@freebsd.org, current Message-ID: <20060106203120.GE51452@cirb503493.alcatel.com.au> References: <20060105093220.GJ1358@svcolo.com> <200601050947.k059lctk024288@hugo10.ka.punkt.de> <20060106103440.GB54324@svcolo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060106103440.GB54324@svcolo.com> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc Cc: Subject: Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2006 20:31:23 -0000 On Fri, 2006-Jan-06 02:34:40 -0800, Jo Rhett wrote: >On Thu, Jan 05, 2006 at 10:47:38AM +0100, Patrick M. Hausen wrote: >> While I agree with much of your reasoning, I know exactly zero >> people running a modified kernel of any version of Windows, >> Mac OS X or Solaris, to name just three commercial OS's. > >You're tickling a different subject here. All three of these operating >systems have loadable kernel modules that work. As does FreeBSD. > I mean, they dynamically >load the modules they need, and you can disable kernel modules in >configuration files. FreeBSD has loadable kernel modules, but they don't >autoload (you have to modify rc files) This isn't quite true. FreeBSD does not currently have the tools to automatically load kernel modules for most hardware device drivers and they need to either be built into the kernel or specified in loader.conf. Writing a tool to do this automatically would be fairly simple - either use pciconf(8) and a database of PCI ID to driver mappings or (as Solaris and X do) load every module and see if it can attach to anything, unload it if it can't. To date, no-one has been sufficiently motivated to do so. FreeBSD will autoload kernel modules for many software functions if their functionality is required (NFS, SysV IPC, firewalls). In some cases this is automatic (NFS client loads automatically if NFS filesystems are found). In other cases, (eg firewalls) you need to configure the functionality anyway. > and you can't trim down the kernel >to minimize unused memory without recompiling. In the absence of tools to automatically detect your configuration and load the appropriate modules, GENERIC includes a fairly standard set of drivers that also exist as modules. GENERIC probably could be cut down somewhat but this isn't the forum to discuss that. >To give you a specific example: if we could remove NFS and the 3ware >driver from the kernel in a configuration file, we could probably run >GENERIC. IMHO, NFS server could be removed without problems (it will autoload), as could tw{a,e} (which are loadable). NFS client can't be removed because it has to be built in to support diskless operation. >hog we have to remove on small footprint systems FreeBSD has never claimed to optimally support small footprint systems without customisation. There are too many variables and some kernel functionality can't be readily converted to modules (eg IPv6 support). In any case, the way to minimise the kernel footprint is to statically load all the required functionality and not have any modules. -- Peter Jeremy