Date: Thu, 2 Nov 2000 15:35:41 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: kris@FreeBSD.ORG (Kris Kennaway) Cc: davep@afterswish.com (David Preece), freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD in good standing in netcraft survey Message-ID: <200011021535.IAA08227@usr09.primenet.com> In-Reply-To: <20001102013134.A23799@citusc17.usc.edu> from "Kris Kennaway" at Nov 02, 2000 01:31:34 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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 terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011021535.IAA08227>