Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 01 Sep 2004 17:14:34 -0700
From:      Julian Elischer <julian@elischer.org>
To:        Brooks Davis <brooks@one-eyed-alien.net>
Cc:        julian@freebsd.FreeBSD.ORG
Subject:   Re: if_data size issues
Message-ID:  <413665EA.30003@elischer.org>
In-Reply-To: <20040902000637.GA4120@odin.ac.hmc.edu>
References:  <20040901193445.GC12483@odin.ac.hmc.edu> <41364415.9040708@elischer.org> <20040902000637.GA4120@odin.ac.hmc.edu>

next in thread | previous in thread | raw e-mail | index | archive | help


Brooks Davis wrote:

>On Wed, Sep 01, 2004 at 02:50:13PM -0700, Julian Elischer wrote:
>  
>
>>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.
>>    
>>
>
>I dug into the RFCs and found that ifCounterDiscontinuityTime is of type
>TimeStamp which is a TimeTick with the epoch of sysUpTime.  The
>resolution of a TimeTick is 1/100s.  Thus, given our choice of counters,
>struct timeval is most appropriate.  However, in this case, meeting the
>letter of the rule is arguably unnecessary.
>
>Given the pain this change is causing and the limited impact of reducing
>the precision of ifi_epoch, I propose the following:
>
> - Back out the ifi_epoch addition.
> - MT5 and MT4 Peter's size change.
> - Turn ifi_unused into ifi_epoch.
> - After 5.3 is released, declare that upgrades to 6.0 from releases
>   other then 4.x (x>=11) and 5.y (y>=3) require special handling and
>   allow if_data to grow as demand requires.
> - If additional precision is deemed necessary at some future date,
>   add a second ifi_epoch_tv.
>

sounds ok to me except that it should actually work from 4.x and 5.2 for 
a while.. say 6 months or so..
a lot of people run along the -current branch but don't upgrade every day..
after 6 months or so probably most of them will have moved onto 
something that can cope.

Are there consumers of this info other than ifconfig?   netstat? natd? 
route? etc?

>
>-- Brooks
>
>  
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?413665EA.30003>