if_data size issues

Peter Wemm peter at wemm.org
Thu Sep 2 12:12:19 PDT 2004


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

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.

-- 
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5


More information about the freebsd-arch mailing list