if_data size issues
Julian Elischer
julian at elischer.org
Wed Sep 1 17:14:35 PDT 2004
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
>
>
>
More information about the freebsd-arch
mailing list