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

[Jo Rhett]

> >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.
 
> On Fri, 2006-Jan-06 02:34:40 -0800, Jo Rhett wrote:
> >You're tickling a different subject here.  All three of these operating
> >systems have loadable kernel modules that work.
 
On Sat, Jan 07, 2006 at 07:31:20AM +1100, Peter Jeremy wrote:
> As does FreeBSD.
 
No.  See below.

> >  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
[cut more explanation of the "state of" which we both know]

Let me rephrase it for you.  One cannot run GENERIC on FreeBSD (like on
these platforms) because one has to REMOVE drivers from the kernel in order
to successfully use the hardware.

Vendor supplies updated driver (.ko) for hardware.  But you can't use this
without either re-compiling the kernel with the new driver, or recompiling
the kernel with that driver disabled.  In either case, no GENERIC for you.

This isn't true on any of the platforms above you have named.  Thus,
freebsd doesn't have a loadable modules interface that works well enough
for this situation.

> >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.

We don't need either, we just need those resources (memory) back.
 
And back to the topic: this is why we can't run FreeBSD GENERIC, but
nobody has to tune their kernels on the major OSes ;-)

> >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.

Either way, it's non GENERIC.  So you have strongly and clearly made my own
arguement for me about why you have to modify GENERIC on FreeBSD but not
on the other major OSes.

-- 
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation