Re: Faure is back..
Jason Gunthorpe <jgg@ualberta.ca> writes:
> On Fri, 29 Sep 2000, Christopher C. Chimelis wrote:
>
> > Fantastic! Thank you, Jason! I meant to provide positive feedback on the
> > 6bone experiments that I tried, but ran out of time to write the
> > emails. For all interested, 6bone works very well on Alpha (as does all
> > other IPv6-friendly stuff that I tried)...definitely encouraging (not even
> > one unaligned trap in my experiments).
>
> Apparently this is going to get broken soon I was told.. New kernels
> changed something for 64 bit platforms, I don't know the details too much?
Well there is this problem...
Artur Frysiak <wiget@pld.org.pl> says:
# ltrace netstat 2>&1|grep getnameinfo
getnameinfo(0xbfffd284, 24, 0x0805d4a0, 255, 0) = -1
fprintf(0x002359a0, "getnameinfo: %s\n", "Bad value for ai_flags"getnameinfo: Bad value for ai_flags
If I use netstat compiled with glibc 2.1.94 then all is fine.
# ltrace netstat 2>&1|grep getnameinfo
getnameinfo(0xbfffd280, 28, 0x0805c1e0, 255, 0) = 0
getnameinfo(0xbfffd280, 28, 0x0805c1e0, 255, 0) = 0
Ulrich Drepper <drepper@redhat.com> says:
The immediate reason for the problem you see is that the sockaddr_in6
structure changed. Complain the the appropriate working group, they
added an sin6_scope_id field. getnameinfo() tests for the size of the
passed-in address structure (the second parameter marks the size) and
fails if it is too small. You will have to recompile all IPv6 enabled
programs. I'll add a comment about this in the documentation.
Artur Frysiak <wiget@pld.org.pl> says:
If changing sockaddr_in6 breaks backword compatibility with glibc 2.1.3 of
getnameinfo then maybe ist time to drop getnameinfo(GLIBC_2.1) versioned
symbol and introduce getnameinfo(GLIBC_2.2) ?
Ulrich Drepper <drepper@redhat.com> says:
It's only changing for IPv6 and IPv6 is in flux. Everybody using it
must be aware of it. I don't want to introduce all this hassle just
because those $%%/§ in the IPv6 working group don't get their acts
together.
...but that isn't a 32/64 issue AFAIK.
--
James Antill -- james@and.org
"If we can't keep this sort of thing out of the kernel, we might as well
pack it up and go run Solaris." -- Larry McVoy.
Reply to: