From owner-freebsd-arch@FreeBSD.ORG Wed Sep 1 23:32:54 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 A84D116A4CE; Wed, 1 Sep 2004 23:32:54 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85ABA43D53; Wed, 1 Sep 2004 23:32:54 +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 5F7EB7A3E1; Wed, 1 Sep 2004 16:32:54 -0700 (PDT) Message-ID: <41365C26.6050209@elischer.org> Date: Wed, 01 Sep 2004 16:32:54 -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> <41364415.9040708@elischer.org> <20040901222038.GA12783@odin.ac.hmc.edu> In-Reply-To: <20040901222038.GA12783@odin.ac.hmc.edu> Content-Type: text/plain; charset=ISO-8859-1; 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 23:32:54 -0000 Brooks Davis wrote: >On Wed, Sep 01, 2004 at 02:50:13PM -0700, Julian Elischer 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. >> >> > >It probably doesn't need to be, but that only puts off the problem by >using the last remaining space. I initially used struct timeval because >that's what ifi_lastchange used. > But if we put in the length field now in 4.x and use the u_long for time, we move a lot of our users out of the problem space.. What goes into 5.3 will basically be a the frozen ABI for the life of 5.x it can change for 6.x as long as 5.3+ and 4.11+ clients can cope. but it should be done at a time when the majority of 5.x people have moved onto the version that has the length change. >If we decied to go this route, I'd be inclined to turn that variable >into a time_t since it's the right width or smaller on all architectures >(I believe struct padding will take care of the extra space on alpha, >but we'll need to check). Bumping time_t to 64-bit on 32-bit arches >will break the ABI will break due to ifi_lastchange so that's not a >consideration. > > Whatever is practical. The BSD rule has always been: "ABI compatibility is always kept for at least 1 major revision." >-- Brooks > > >