From owner-freebsd-arch@FreeBSD.ORG Wed Sep 1 21:50:14 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 A22C816A4CE; Wed, 1 Sep 2004 21:50:14 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69ADD43D1D; Wed, 1 Sep 2004 21:50:14 +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 0E1177A403; Wed, 1 Sep 2004 14:50:14 -0700 (PDT) Message-ID: <41364415.9040708@elischer.org> Date: Wed, 01 Sep 2004 14:50:13 -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: Brooks Davis References: <20040901193445.GC12483@odin.ac.hmc.edu> In-Reply-To: <20040901193445.GC12483@odin.ac.hmc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: scottl@freebsd.org cc: julian@freebsd.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:50:14 -0000 Brooks Davis wrote: >My recent commit to net/if.h adding ifi_epoch to struct if_data had >unintended consequences. Specifically, because of the way ifconfig >uses RTM_IFINFO routing socket messages via sysctl to obtain interface >information, the value of sizeof(struct if_data) must be the same in the >kernel and userland. I have committed a fix from Peter which allows >ifconfig to handle growth of struct if_data. Unfortunately, this does >not fix old ifconfigs with new kernels. > What is the reason that ifi_epoch needs to be accurate the microsecond? you have a u)long just next door that is unused that could hold a seconds count that would last at least 68 years if expressed as a count from boot time. > >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. 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. I haven't actually done >it, but by observation, Peter's fix should apply cleanly all the way >back to RELENG_2_2 so we could MFC the change as far back as we like >thus providing people the ability to build a new ifconfig that works on >any system. Upgrades could then be handled either by doing a two-stage >upgrade or by preinstalling a new ifconfig. IIRC, we have required the >two-stage upgrade for some version bumps in the past. It it probably >even possible, if non-trivial to add a seatbelt to installkernel to >prevent installation of a new kernel without a new ifconfig. > >I believe that providing backwards compatibility for ifconfig would >be fairly difficult as it would require the creation of new values of >RTM_IFINFO and NET_RT_IFLIST, a struct oif_data, a struct oifm_msghdr, >and duplication of significant code in rtsock.c. We would also have >to maintain this duplicate code in the future. In practice, I think >requiring this level of binary compatibility would prevent additions >to struct if_data (beyond one currently unassigned u_long variable). > >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. > >The commits to add ifi_epoch were: > >sys/net/if.c:1.201 >sys/net/if.h:89 > >The changes to allow ifconfig to handle different sizes for struct >if_data were: > >sbin/ifconfig/ifconfig.c:1.107 >sys/net/if.c:1.202 >sys/net/if.h:90 > >-- Brooks > > >