From owner-freebsd-arch@FreeBSD.ORG Wed Sep 1 21:56:05 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58C0816A4CF; Wed, 1 Sep 2004 21:56:05 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3149E43D41; Wed, 1 Sep 2004 21:56:05 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 241617A3E1; Wed, 1 Sep 2004 14:56:05 -0700 (PDT) Message-ID: <41364574.8070201@elischer.org> Date: Wed, 01 Sep 2004 14:56:04 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Garance A Drosihn References: <20040901193445.GC12483@odin.ac.hmc.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: scottl@freebsd.org Subject: Re: if_data size issues X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2004 21:56:05 -0000 Garance A Drosihn wrote: > At 12:34 PM -0700 9/1/04, Brooks Davis wrote: > >> >> Julian raises a valid point that this can cause problems for updates >> over the network. At this point we disagree on the severity of the >> problem. >> >> He says old binaries must work with new kernels. I argue that >> network updates are an edge case, a critically important one, but >> an edge case non-the-less. > > > IMO it is a more significant than just an edge-case, particularly > since it includes nfs-mounted installs. But that's just MO. > >> Because it is an edge case, I believe it would be acceptable to >> require an extra step in the upgrade process. That step is simply >> installing a new ifconfig binary. > > > My immediate reaction is that we could probably do something like > this, although we would have to think a bit about the best way to > get it done. We could certainly install the fix from Peter in the > 4.10-stable and 4.10-errata branches, for instance. It shouldn't > hurt anything to have that fix installed ASA-SufficientlyTested. And people upgrading from (say) 4.8 ?(we have 1000 machines on 4.8 in active production.. i.e. no patches.. no changes.. no nothing except when approved in tripplicate and with your first-born held as hostage in case they need you to back it out) > > >> I would appreciate other opinions on this issue as we need to either >> back out both of these changes or begin MFCing the ifconfig changes. > > > Perhaps we could do something like have the update process require > an "ifconfig5" (or some other unique name), and use that if it > exists. Not sure that is a great idea, but it gives us an easy > way to make sure the system has the right binary. 'installkernel' > could just stop if the needed binary is not on the destination > system. > > Some of the tricks I used in the 64-bTT upgrade on sparc64 might > also be of interest, although I have to run right now so I can't > come up with the specifics at the moment. I am not convinced we even have a problem.. why is the new field a timeval? why not a second count? there's room there for that... and we could give ourselves from 5.x to 6.x to let the 'size' field become "usual". > >