if_data size issues

[Brooks Davis]

On Thu, Sep 02, 2004 at 12:12:18PM -0700, Peter Wemm wrote:
> On Wednesday 01 September 2004 10:14 pm, Brooks Davis wrote:
> > On Wed, Sep 01, 2004 at 09:49:45PM -0400, Garance A Drosihn wrote:
> > > In a later message, Brooks Davis wrote:
> > > >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.
> > >
> > > Given the time-constraints in that we want a solution "right now",
> > > these seem like good ideas.
> >
> > I've done the backout and will submit Peter's change for MT5 on the
> > 4th. I'll do the ifi_unused => ifi_epoch change soon, but I need to
> > verify my theory that I can use a time_t without changing the struct
> > size.
> 
> There is only one minor gotcha on this one.. Alpha.  sizeof(time_t) == 
> sizeof(u_long) on all our platforms except alpha.  (note I said sizeof, 
> not typeof).

Yup I noticed that.

> An additional pad would be needed on alpha to compensate.  eg:
>         u_long  ifi_hwassist;           /* HW offload capabilities */
>         time_t  ifi_epoch;
> #ifdef __alpha__
>  u_int ifi_timepad;   /* time_t is int, not long on alpha */
> #endif
>         struct  timeval ifi_lastchange; /* time of last administrative 
> change */
> 
> Actually, now that I look at it.. timeval begins with a 'long', so it'll 
> be aligned correctly on alpha anyway, even without adding ifi_timepad.  
> I personally like documenting hidden padding when there are abi issues 
> though.

I wrote a little test program and yes, alpha keeps the size the same due
to padding (I thought it would, but figured the two minutes required to
check were worth it. :-). I will use the explict pad though.  That will
hopefully keep people from being confused in the future.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20040902/0a3cb837/attachment-0001.bin