Date: Wed, 1 Sep 2004 15:20:38 -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: <20040901222038.GA12783@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
--7JfCtLOvnd9MIVvH 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 > >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. It probably doesn't need to be, but that only puts off the problem by using the last remaining space. I initially used struct timeval because that's what ifi_lastchange used. If we decied to go this route, I'd be inclined to turn that variable into a time_t since it's the right width or smaller on all architectures (I believe struct padding will take care of the extra space on alpha, but we'll need to check). Bumping time_t to 64-bit on 32-bit arches will break the ABI will break due to ifi_lastchange so that's not a consideration. -- 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 --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD4DBQFBNks2XY6L6fI4GtQRAu2jAJURVRLTW9u5ODbbdxmDUtQ0zbJVAJ0StXxx HDy8pjG59+bWD9plZ4hK/w== =YZWG -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040901222038.GA12783>