From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org,
GNU libc hackers <libc-hacker@sources.redhat.com>,
libc-alpha@sources.redhat.com
Subject: More sigevent ...
Date: Wed, 03 Sep 2003 12:57:00 -0000 [thread overview]
Message-ID: <20030903125734.GA9260@linux-mips.org> (raw)
In-Reply-To: <20030831164812.GB766@bogon.ms20.nix>
Looking into the problem a bit deeper here's my analysis of the whole
missmatch of struct sigevent and the associated constants, including the
entire history.
- Linux 2.1.72 introduces sigevent. The definition used is the one taken
from IRIX and different from what is used in other Linux ports. But
that doesn't matter because there are no in-kernel users.
I don't know why the structure was defined at all in kernel headers at
all by that time. Maybe for the sake of libc 5?
- Some of the >= libc 2.1 version circulating use the kernel definitions
- Andreas Jaeger contributes sysdeps/unix/sysv/linux/mips/bits/siginfo.h
for the FSF version of glibc 2.1. Markedrd as "XXX This one might need
to change!!!" this header file uses the same structure as other Linux
architectures but uses the same SIGEV_* constants as the kernel.
- Linux 2.5.63 introduces the POSIX.1b timer API which uses the kernel's
definition of sigevent. The userspace part of the POSIX.1b timer patch
uses glibc's definition. But the code assumes both definitions are
identical ...
Time to resolve the mess. I see the following options:
- Yet another syscall wrapper that does argument conversion. Imho the
most icky solution.
- Change the kernel to use the same definition as glibc. Not really an
option, SIGEV_CALLBACK has to go.
- Two part solution:
- Change the kernel definition to what other architectures use (Done,
may have to be undone depending on the outcome of this discussion).
- Remove SIGEV_CALLBACK from glibc which would result in SIGEV_THREAD
getting renumbered to the same value as in the kernel.
(This is in my withdrawn libc patch from the weekend.)
Grepping around in plenty of Linux code I've not found any users of
SIGEV_THREAD so this would be my prefered solution.
SIGEV_CALLBACK would have to be removed in any case; it's a dead
definition with no functionality. Is it supposed to do what
SIGEV_THREAD_ID does? I've been digging around in parts of the Redhat 9
source code and haven't found any users of SIGEV_THREAD, so it seems
this is a very rarely used feature and we can change without any major
compatibility issues.
Comments?
Ralf
prev parent reply other threads:[~2003-09-03 12:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-31 14:59 [PATCH] Fix sigevent_t stuff Ralf Baechle
2003-08-31 16:12 ` Ralf Baechle
[not found] ` <20030831164812.GB766@bogon.ms20.nix>
2003-09-03 12:57 ` Ralf Baechle [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030903125734.GA9260@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=libc-alpha@sources.redhat.com \
--cc=libc-hacker@sources.redhat.com \
--cc=linux-mips@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).