Date: Wed, 01 Sep 2004 14:50:13 -0700 From: Julian Elischer <julian@elischer.org> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: julian@freebsd.FreeBSD.ORG Subject: Re: if_data size issues Message-ID: <41364415.9040708@elischer.org> In-Reply-To: <20040901193445.GC12483@odin.ac.hmc.edu> References: <20040901193445.GC12483@odin.ac.hmc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Brooks Davis wrote: >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. > 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 seconds count that would last at least 68 years if expressed as a count from boot time. > >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 > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41364415.9040708>