Date: Wed, 1 Sep 2004 17:34:01 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: Julian Elischer <julian@elischer.org> Cc: julian@freebsd.FreeBSD.ORG Subject: Re: if_data size issues Message-ID: <20040902003401.GA14224@odin.ac.hmc.edu> In-Reply-To: <413665EA.30003@elischer.org> References: <20040901193445.GC12483@odin.ac.hmc.edu> <41364415.9040708@elischer.org> <20040902000637.GA4120@odin.ac.hmc.edu> <413665EA.30003@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 01, 2004 at 05:14:34PM -0700, Julian Elischer wrote: >=20 >=20 > Brooks Davis wrote: >=20 > >On Wed, Sep 01, 2004 at 02:50:13PM -0700, Julian Elischer wrote: > >=20 > > > >>Brooks Davis wrote: > >> > >> =20 > >> > >>>My recent commit to net/if.h adding ifi_epoch to struct if_data had > >>>unintended consequences. Specifically, because of the way ifconfig > >>>uses RTM_IFINFO routing socket messages via sysctl to obtain interface > >>>information, the value of sizeof(struct if_data) must be the same in t= he > >>>kernel and userland. I have committed a fix from Peter which allows > >>>ifconfig to handle growth of struct if_data. Unfortunately, this does > >>>not fix old ifconfigs with new kernels. > >>> =20 > >>> > >>What is the reason that ifi_epoch needs to be accurate the microsecond? > >>you have a u)long just next door that is unused that could hold a=20 > >>seconds count that would last > >>at least 68 years if expressed as a count from boot time. > >> =20 > >> > > > >I dug into the RFCs and found that ifCounterDiscontinuityTime is of type > >TimeStamp which is a TimeTick with the epoch of sysUpTime. The > >resolution of a TimeTick is 1/100s. Thus, given our choice of counters, > >struct timeval is most appropriate. However, in this case, meeting the > >letter of the rule is arguably unnecessary. > > > >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. > >- 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 > sounds ok to me except that it should actually work from 4.x and 5.2 for= =20 > a while.. say 6 months or so.. > a lot of people run along the -current branch but don't upgrade every day= .. > after 6 months or so probably most of them will have moved onto=20 > something that can cope. The exact schedual is flexable. I just want it to be reasionable soon. 5.4-RELEASE might be a decent cut off. Then there will be 5.3, 5.4, and 4.11 as safe update points. > Are there consumers of this info other than ifconfig? netstat? natd?=20 > route? etc? There are a number of other consumers, but most of them won't matter. We will need to audit them to be sure, but so far most have been things like netstat that are unimportant. -- 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 --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBNmp5XY6L6fI4GtQRAgs2AKCNtnv3ds8lbW4CplsD6cJyiPrFZwCfZ2Z4 Xn5thuXpG1WmrCGLhVPRnFw= =WpHY -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040902003401.GA14224>