From owner-freebsd-hackers Thu Nov 2 7:36: 7 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id EE0D637B4C5; Thu, 2 Nov 2000 07:36:03 -0800 (PST) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id IAA05882; Thu, 2 Nov 2000 08:34:14 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp03.primenet.com, id smtpdAAA1Za4tl; Thu Nov 2 08:33:55 2000 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id IAA08227; Thu, 2 Nov 2000 08:35:41 -0700 (MST) From: Terry Lambert Message-Id: <200011021535.IAA08227@usr09.primenet.com> Subject: Re: FreeBSD in good standing in netcraft survey To: kris@FreeBSD.ORG (Kris Kennaway) Date: Thu, 2 Nov 2000 15:35:41 +0000 (GMT) Cc: davep@afterswish.com (David Preece), freebsd-hackers@FreeBSD.ORG In-Reply-To: <20001102013134.A23799@citusc17.usc.edu> from "Kris Kennaway" at Nov 02, 2000 01:31:34 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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