Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 1 Sep 2004 17:06:37 -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:  <20040902000637.GA4120@odin.ac.hmc.edu>
In-Reply-To: <41364415.9040708@elischer.org>
References:  <20040901193445.GC12483@odin.ac.hmc.edu> <41364415.9040708@elischer.org>

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

--qDbXVdCdHGoSgWSk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 01, 2004 at 02:50:13PM -0700, Julian Elischer wrote:
>=20
>=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 the
> >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.

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.

-- 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

--qDbXVdCdHGoSgWSk
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFBNmQMXY6L6fI4GtQRAn+sAJ9Jss/JgMyDzv651JUdtCWKSVHvdwCeK5eA
9PDn4A7pkl8jKzkRmoBaLQo=
=M5BZ
-----END PGP SIGNATURE-----

--qDbXVdCdHGoSgWSk--



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