if_data size issues

[Julian Elischer]

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
>
>  
>