[ILUG] [TOTD] find error corresponding to number

[Paul Jakma]

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 
link to.

If the signal number were to change, there would likely still be an
old_SIGFOO or, more likely, a seperate header defining the backwards
compat constants.
 
> 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
non-libc-using apps.

> 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
are?

regards,
-- 
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
	warning: do not ever send email to spam at dishone.st
Fortune:
I love dogs, but I hate Chihuahuas.  A Chihuahua isn't a dog.  It's a rat
with a thyroid problem.