Date: Thu, 02 Sep 2004 00:49:56 -0700 From: Julian Elischer <julian@elischer.org> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: Garance A Drosihn <drosih@rpi.edu> Subject: Re: if_data size issues Message-ID: <4136D0A4.9000407@elischer.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. yes I believe 5.2->6.0-current@X where X is a point in time a bit down the road, is not an important conversion, as very few people will be doing it... those who are running 5.2 will probably jump to either 5.3 or 6.0 within a relatively short time. those who go to 6 from 4 will probably go to 4.11 or more or 5.3+ first. > > -- Brooks >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4136D0A4.9000407>