Date: Wed, 01 Sep 2004 16:32:54 -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: <41365C26.6050209@elischer.org> In-Reply-To: <20040901222038.GA12783@odin.ac.hmc.edu> References: <20040901193445.GC12483@odin.ac.hmc.edu> <41364415.9040708@elischer.org> <20040901222038.GA12783@odin.ac.hmc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Brooks Davis wrote: >On Wed, Sep 01, 2004 at 02:50:13PM -0700, Julian Elischer 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. >> >> > >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. > But if we put in the length field now in 4.x and use the u_long for time, we move a lot of our users out of the problem space.. What goes into 5.3 will basically be a the frozen ABI for the life of 5.x it can change for 6.x as long as 5.3+ and 4.11+ clients can cope. but it should be done at a time when the majority of 5.x people have moved onto the version that has the length change. >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. > > Whatever is practical. The BSD rule has always been: "ABI compatibility is always kept for at least 1 major revision." >-- Brooks > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41365C26.6050209>