Messages in this thread | | | Date | Tue, 10 Feb 2004 10:20:52 +0100 | From | Lars Marowsky-Bree <> | Subject | siginfo_t si_band type mismatch between kernel & glibc |
| |
Morning,
it turns out that on some archs, si_band is defined as long in the glibc headers and as int in the kernel, leading to a 'nice' struct mismatch and quite interesting behaviour - ie, breaking SIGPOLL & SIGIO on most 64bit archs.
In 2.6, we find:
#ifndef __ARCH_SI_BAND_T #define __ARCH_SI_BAND_T int #endif ... /* SIGPOLL */ struct { __ARCH_SI_BAND_T _band; /* POLL_IN, POLL_OUT, POLL_MSG */ int _fd; } _sigpoll;
Alas, for all archs but x86_64, __ARCH_SI_BAND_T is not defined, thus defaulting to int, which is still not matching the user space expectations.
http://linux.bkbits.net:8080/linux-2.5/diffs/include/asm-generic/siginfo.h@1.10?nav=index.html|src/|src/include|src/include/asm-generic|hist/include/asm-generic/siginfo.h suggests that Linus believes _band should be int on all archs but x86_64.
However, the glibc has had it as 'long' on mips, ia64 and x86_64 in the kernel-headers; the glibc/sysdeps differs from this further, as it is long only on linux(generic), ia64, s390. And the manpage says it to be int, fwiw.
So is this a kernel bug or a glibc one? ;-)
Most user-land seems to expect it to be long, and right now (in 2.4 + 2.6), it seems SIGIO is definetely broken on ppc64 / s390x.
Sincerely, Lars Marowsky-Brée <lmb@suse.de>
-- High Availability & Clustering \ ever tried. ever failed. no matter. SUSE Labs | try again. fail again. fail better. Research & Development, SUSE LINUX AG \ -- Samuel Beckett
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |