Re: if_data size issues

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

  • Next message: Scott Long: "Re: if_data size issues" 
    Date: Wed, 1 Sep 2004 22:14:15 -0700
To: Garance A Drosihn <drosih@rpi.edu>

    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.

    > > - After 5.3 is released, declare that upgrades to 6.0 from releases
    > > other then 4.x (x>=11) and 5.y (y>=3) require special handling
    > > and allow if_data to grow as demand requires.
    > > - If additional precision is deemed necessary at some future date,
    > > add a second ifi_epoch_tv.
    >
    > We do not have to come to an agreement on these steps until we are
    > ready to make additional changes to the structure. Something along
    > these lines seems reasonable to me, but I don't think that we have
    > to declare any specific timetables right now.

    Agreed. I think it would be useful to declare upfront that should a
    change be made, we are willing to jetison full, offical support for
    upgrades to 6.0 from 5.x (x<3), but that's a minor detail.

    -- 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: Scott Long: "Re: if_data size issues"

    Relevant Pages

    • Re: if_data size issues
      ... Brooks Davis wrote: ... > theory that I can use a time_t without changing the struct size. ... I think it would be useful to declare upfront that should a ... conversion, as very few people will be doing it... ...
      (freebsd-arch)
    • Re: if_data size issues
      ... Brooks Davis wrote: ... > theory that I can use a time_t without changing the struct size. ... >>to declare any specific timetables right now. ... reasonable position to take. ...
      (freebsd-arch)
    • proposed new if_data variable
      ... It will be set to the time the counters were zeroed, ... Since this will increase the size of struct if_data and thus struct ... the change needs to be made now if it's going to be made for ... From: Brooks Davis ...
      (freebsd-net)