> > BTW, we didn't fare very well at all in the top *average*
> > uptimes. Sun OTOH, did. Bugger.
>
> IMO, this can be plausibly explained by the availability of updated
> code for the two platforms. With Sun they release patches relatively
> infrequently, kernel patches less frequently still..OTOH FreeBSD
> "releases patches" many times each day, encouraging the admin to
> upgrade frequently to scratch the itch of being "up to date".
This is an artifact of FreeBSD kernel modularity not being
what it should be, rather than the (in)frequency of patches,
one way or another.
I personally think I should be able to "hot swap" any kernel
subsystem, including the VM code, without rebooting my machine.
The techniques for implementing this are both obvious and well
known from object oriented programming:
o Make all structures opaque
o Use indirect reference to opaque objects
o Use accessors and mutators, instead of direct
structure element references
o Only force a more complex upgrade when an accessor
or mutator goes away in a provider, or a non-existant
one starts being referenced by a consumer
o Unless there are two mutually dependent subsystem
modules (which is a broken object model, BTW), even
in the more complex case, you can upgrade by doing
a series upgrade, and tracking dependencies; this
would mean externalizing imported and exported
accessor/mutator references (and object types, if
a new opaque object type comes into existance),
but it's still quite doable. You would also need
to version by interface instance, not provider of
interfaces, to ensure that member function argument
changes could be tracked.
NB: This last technique is vastly superior to the way
FreeBSD handles shared libraries, actually, since
if anything like this changes in a shared library,
you have to keep two copies of a library around,
since a FreeBSD shared library can't export two
different versions of the same interface to a
library consumer. Also, since you could similarly
version system calls, you'd avoid the mount/newmount
screwup that FreeBSD has had dampening the "build
world" upgrade process a number of times in the
past.
Terry Lambert
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
