Date: Wed, 01 Sep 2004 14:56:04 -0700 From: Julian Elischer <julian@elischer.org> To: Garance A Drosihn <drosih@rpi.edu> Cc: scottl@freebsd.org Subject: Re: if_data size issues Message-ID: <41364574.8070201@elischer.org> In-Reply-To: <p06110436bd5beaf7676b@[128.113.24.47]> References: <20040901193445.GC12483@odin.ac.hmc.edu> <p06110436bd5beaf7676b@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
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". > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41364574.8070201>