cvs commit: src UPDATING src/sys/sys param.h src/sys/net if.c
brooks at one-eyed-alien.net
Tue Aug 31 18:02:30 PDT 2004
On Tue, Aug 31, 2004 at 05:46:50PM -0700, Peter Wemm wrote:
> On Monday 30 August 2004 05:43 pm, Brooks Davis wrote:
> > On Mon, Aug 30, 2004 at 05:29:22PM -0700, Peter Wemm wrote:
> > > On Monday 30 August 2004 02:53 pm, Brooks Davis wrote:
> > > > On Mon, Aug 30, 2004 at 05:34:23PM -0400, Andrew Gallatin wrote:
> > > > > Brooks Davis writes:
> > > > > > I don't think so. The main offenders will be programs that
> > > > > > walk the interface list via libkvm and programs that use
> > > > > > struct if_data. ifconfig does neither. If you haven't
> > > > > > recompiled a module, a non-working ifconfig might result if
> > > > > > by some miracle you didn't get a panic on attach.
> > > > >
> > > > > ppc does not even build modules, so that's out. An older
> > > > > ifconfig pukes, while a new one works, so some sort of
> > > > > kernel/userland ABI must have changed in the last week. Has
> > > > > the data exported by sysctl changed recently?
> > > >
> > > > I think I found it, at least partially. The issue is struct
> > > > if_msghdr which is used by ifconfig. It contains a struct
> > > > if_data. It has grown by a struct timeval. The weird thing is
> > > > that this shouldn't be a problem becuase if_msghdr has a length
> > > > and my addition was to the end so ifconfig should be able to skip
> > > > over it, but it doesn't seem to actually work.
> > >
> > > It is broken on amd64 too, FWIW.
> > If if_msghdr is the problem, it will be broken on all platforms and a
> > rebuild of everything thing should fix it. I don't know why ifconfig
> > is having a problem with the extension of if_msghdr. It shouldn't
> > care since the format is unchanged other then the addition of a
> > structure at the very end and the ifm_msglen member appears to be
> > used correct to advance through the array passed by the sysctl.
> Actually, I more want to know why it didn't work. But I haven't figured
> out where the message lengths are even getting set, let alone
> (mis?)used by ifconfig.
The if_msghdrs are used in the loop that starts around line 582 in
ifconfig.c. That seems to correct. The length seems to be set in in
net/rtsock.c in the rt_msg1 and rt_msg2 functions. The reason it's so
darn hard to find is that routing messages are defined by different
structs with the same first several members. Due to the naming of the
members, that renders grep useless. :-( I can't help but think
someone was too clever for their own good. I still don't see why
it's breaking though since that should set the values. The only thing I
can think of is that there's a dependency tracking bug somewhere, but
that seems unlikely which would seem to indicate that I'm not on to the
real cause yet. :-(
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-all/attachments/20040831/9a2ff5fc/attachment.bin
More information about the cvs-all