From owner-freebsd-arch@FreeBSD.ORG Thu Sep 2 09:58:49 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 33FE116A4CE for ; Thu, 2 Sep 2004 09:58:49 +0000 (GMT) Received: from n33.kp.t-systems-sfr.com (n33.kp.t-systems-sfr.com [129.247.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CC7C43D1D for ; Thu, 2 Sep 2004 09:58:48 +0000 (GMT) (envelope-from harti@freebsd.org) Received: from n81.sp.op.dlr.de (n81g.sp.op.dlr.de [129.247.163.1]) i829wR2306550; Thu, 2 Sep 2004 11:58:27 +0200 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) i829wRI76636; Thu, 2 Sep 2004 11:58:27 +0200 Received: from beagle.kn.op.dlr.de (opkndnwsbsd178 [129.247.173.178]) by zeus.nt.op.dlr.de (8.11.7+Sun/8.9.1) with ESMTP id i829wMe29529; Thu, 2 Sep 2004 11:58:25 +0200 (MET DST) Date: Thu, 2 Sep 2004 11:58:22 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt@beagle.kn.op.dlr.de To: Julian Elischer In-Reply-To: <413665EA.30003@elischer.org> Message-ID: <20040902113909.M26182@beagle.kn.op.dlr.de> References: <20040901193445.GC12483@odin.ac.hmc.edu> <41364415.9040708@elischer.org> <20040902000637.GA4120@odin.ac.hmc.edu> <413665EA.30003@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: if_data size issues X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2004 09:58:49 -0000 On Wed, 1 Sep 2004, Julian Elischer wrote: JE> JE> JE>Brooks Davis wrote: JE> JE>> On Wed, Sep 01, 2004 at 02:50:13PM -0700, Julian Elischer wrote: JE>> JE>> > Brooks Davis wrote: JE>> > JE>> > JE>> > > My recent commit to net/if.h adding ifi_epoch to struct if_data had JE>> > > unintended consequences. Specifically, because of the way ifconfig JE>> > > uses RTM_IFINFO routing socket messages via sysctl to obtain interface JE>> > > information, the value of sizeof(struct if_data) must be the same in JE>> > > the JE>> > > kernel and userland. I have committed a fix from Peter which allows JE>> > > ifconfig to handle growth of struct if_data. Unfortunately, this does JE>> > > not fix old ifconfigs with new kernels. JE>> > > JE>> > What is the reason that ifi_epoch needs to be accurate the microsecond? JE>> > you have a u)long just next door that is unused that could hold a seconds JE>> > count that would last JE>> > at least 68 years if expressed as a count from boot time. JE>> > JE>> JE>> I dug into the RFCs and found that ifCounterDiscontinuityTime is of type JE>> TimeStamp which is a TimeTick with the epoch of sysUpTime. The JE>> resolution of a TimeTick is 1/100s. Thus, given our choice of counters, JE>> struct timeval is most appropriate. However, in this case, meeting the JE>> letter of the rule is arguably unnecessary. JE>> JE>> Given the pain this change is causing and the limited impact of reducing JE>> the precision of ifi_epoch, I propose the following: JE>> JE>> - Back out the ifi_epoch addition. JE>> - MT5 and MT4 Peter's size change. JE>> - Turn ifi_unused into ifi_epoch. JE>> - After 5.3 is released, declare that upgrades to 6.0 from releases JE>> other then 4.x (x>=11) and 5.y (y>=3) require special handling and JE>> allow if_data to grow as demand requires. JE>> - If additional precision is deemed necessary at some future date, JE>> add a second ifi_epoch_tv. JE>> JE> JE>sounds ok to me except that it should actually work from 4.x and 5.2 for a JE>while.. say 6 months or so.. JE>a lot of people run along the -current branch but don't upgrade every day.. JE>after 6 months or so probably most of them will have moved onto something JE>that can cope. JE> JE>Are there consumers of this info other than ifconfig? netstat? natd? route? JE>etc? The SNMP MIB-II module would happily use it I suppose (contrib/bsnmp/snmp_mibII). harti