Date: Wed, 1 Sep 2004 22:14:15 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: Garance A Drosihn <drosih@rpi.edu> Cc: Julian Elischer <julian@elischer.org> Subject: Re: if_data size issues Message-ID: <20040902051415.GA23926@odin.ac.hmc.edu> In-Reply-To: <p06110439bd5c29e42719@[128.113.24.47]> References: <20040901193445.GC12483@odin.ac.hmc.edu> <p06110436bd5beaf7676b@[128.113.24.47]> <41364574.8070201@elischer.org> <p06110439bd5c29e42719@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
--qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > 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 =3D> 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>=3D11) and 5.y (y>=3D3) 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. >=20 > 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 --=20 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 --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBNqwmXY6L6fI4GtQRAvvJAKDncgVgmwatOT8hX2fguY0zKL1abQCglGvy bHqUpKJtB+BSAN3w+h3MRZ0= =Tjno -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040902051415.GA23926>