Date: Wed, 1 Sep 2004 12:34:45 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: arch@freebsd.org Cc: julian@freebsd.FreeBSD.ORG Subject: if_data size issues Message-ID: <20040901193445.GC12483@odin.ac.hmc.edu>
next in thread | raw e-mail | index | archive | help
--Clx92ZfkiYIKRjnr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. Julian raises a valid point that this can cause problems for updates over the network. At this point we disagree on the severity of the problem. He says old binaries must work with new kernels. I argue that network updates are an edge case, a critically important one, but an edge case non-the-less. Because it is an edge case, I believe it would be acceptable to require an extra step in the upgrade process. That step is simply installing a new ifconfig binary. I haven't actually done it, but by observation, Peter's fix should apply cleanly all the way back to RELENG_2_2 so we could MFC the change as far back as we like thus providing people the ability to build a new ifconfig that works on any system. Upgrades could then be handled either by doing a two-stage upgrade or by preinstalling a new ifconfig. IIRC, we have required the two-stage upgrade for some version bumps in the past. It it probably even possible, if non-trivial to add a seatbelt to installkernel to prevent installation of a new kernel without a new ifconfig. I believe that providing backwards compatibility for ifconfig would be fairly difficult as it would require the creation of new values of RTM_IFINFO and NET_RT_IFLIST, a struct oif_data, a struct oifm_msghdr, and duplication of significant code in rtsock.c. We would also have to maintain this duplicate code in the future. In practice, I think requiring this level of binary compatibility would prevent additions to struct if_data (beyond one currently unassigned u_long variable). I would appreciate other opinions on this issue as we need to either back out both of these changes or begin MFCing the ifconfig changes. The commits to add ifi_epoch were: sys/net/if.c:1.201 sys/net/if.h:89 The changes to allow ifconfig to handle different sizes for struct if_data were: sbin/ifconfig/ifconfig.c:1.107 sys/net/if.c:1.202 sys/net/if.h:90 -- 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 --Clx92ZfkiYIKRjnr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBNiRVXY6L6fI4GtQRAq83AJ9QG9UGc12m84GEgB0O7UyO5zt9XACgm3H9 RPaxgfp+QuQlrDCdGrStMv4= =Dw7u -----END PGP SIGNATURE----- --Clx92ZfkiYIKRjnr--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040901193445.GC12483>