On Fri, 7 May 2004, Bryan O'Donoghue wrote:
> Which violates the given postulate, that the signal number has
> changed from version (x) to version (y).
But you didnt read the post of Torvald's which Shirley gave you the
If the signal number were to change, there would likely still be an
old_SIGFOO or, more likely, a seperate header defining the backwards
> If the kernel structures took care of backwards compatability like
> that, there'd be no problem in having another kernel in
> /usr/src/linux then the one you compiled your libc against.
No.. because while the kernel may provide means for backwards
compatibility, those means, as exposed by the kernel header files,
may well not be the linux userspace ABI that applications should use,
it's a libc ABI essentially. So, eg, while glibc is expected to know
the kernel interface(s) dejour and present an acceptable ABI based on
that, nothing else should - they should all use the glibc ABI.
> So if Andrew Morton in a fit of "I'm going to sort some stuff out"
> randomly changed the number the kernel set a task's sig state to,
> such that sigterm and sigkill were now mapped in the opposite
> direction, a script that was grepping the *old* symlinked
> /usr/src/linux + *libc, wouldn't adequately trap that signal number
> and map it back to the correct SIGTERM, SIGINT and those would
> appear to be reversed... if you catch my drift.
What if the kernel's headers defined SIGTERM, SIGINT, etc.. but only
for backwards compatibility? And that your glibc was actually using
the kernel's internal NEWSIGTERM, NEWSIGINT, etc signal numbers as
constants for the traditional UNIX userspace ABI?
Your script would then get it wrong.
Now, the more recent thinking is that the userspace ABI should _not_
be left to glibc. But simply because glibc is rather gigantic and
complex, and there are other C libs out there. So for 2.7 the kernel
perhaps will acquire a set of stable headers defining the userspace
ABI, for use by glibc, other base libraries and (usually) weird
> I don't really think it's the same thing as the "Don't have your
> current kernel source in /usr/src/linux, cause it foobars *libc"
> problem... but, I guess I could be wrong.
You could be I guess, but it's only Linus and a raft of other kernel
developers disagreeing with you. So, hey, how likely is it that you
Paul Jakma paul at clubi.iepaul at jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam at dishone.st
I love dogs, but I hate Chihuahuas. A Chihuahua isn't a dog. It's a rat
with a thyroid problem.
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!