Re: if_data size issues

From: Brooks Davis (brooks_at_one-eyed-alien.net)
Date: 09/02/04

  • Next message: Brooks Davis: "Re: if_data size issues" 
    Date: Thu, 2 Sep 2004 12:51:32 -0700
To: Peter Wemm <peter@wemm.org>

    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 message: Brooks Davis: "Re: if_data size issues"