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