Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]

From: Peter Jeremy <PeterJeremy_at_optushome.com.au>
Date: Sat, 7 Jan 2006 07:31:20 +1100
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
Received on Fri Jan 06 2006 - 19:31:23 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:50 UTC