Date: Wed, 01 Sep 2004 23:21:27 -0600 From: Scott Long <scottl@samsco.org> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: Julian Elischer <julian@elischer.org> Subject: Re: if_data size issues Message-ID: <4136ADD7.6060207@samsco.org> In-Reply-To: <20040902051415.GA23926@odin.ac.hmc.edu> References: <20040901193445.GC12483@odin.ac.hmc.edu> <p06110436bd5beaf7676b@[128.113.24.47]> <41364574.8070201@elischer.org> <p06110439bd5c29e42719@[128.113.24.47]> <20040902051415.GA23926@odin.ac.hmc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > >>>- 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 > Given that we aren't declaring 5-STABLE until 5.3, this is probably a reasonable position to take. Those early adopters of 5.0-5.2.1 should (theorectically) know what they are getting into. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4136ADD7.6060207>