Skip site navigation (1)Skip section navigation (2)
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]>

index | next in thread | previous in thread | raw e-mail

[-- Attachment #1 --]
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

[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFBNqwmXY6L6fI4GtQRAvvJAKDncgVgmwatOT8hX2fguY0zKL1abQCglGvy
bHqUpKJtB+BSAN3w+h3MRZ0=
=Tjno
-----END PGP SIGNATURE-----
home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040902051415.GA23926>