From owner-freebsd-arch@FreeBSD.ORG Thu Sep 2 05:13:48 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E092B16A4CE for ; Thu, 2 Sep 2004 05:13:48 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFA5243D41 for ; Thu, 2 Sep 2004 05:13:48 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i825EFKq025378; Wed, 1 Sep 2004 22:14:15 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i825EFF2025377; Wed, 1 Sep 2004 22:14:15 -0700 Date: Wed, 1 Sep 2004 22:14:15 -0700 From: Brooks Davis To: Garance A Drosihn Message-ID: <20040902051415.GA23926@odin.ac.hmc.edu> References: <20040901193445.GC12483@odin.ac.hmc.edu> <41364574.8070201@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: arch@freebsd.org cc: Julian Elischer Subject: Re: if_data size issues X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2004 05:13:49 -0000 --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--