Subject: Re: SA_SIGINFO patch
To: Christos Zoulas <firstname.lastname@example.org>
From: Jason Thorpe <email@example.com>
Date: 09/03/2003 07:59:45
On Wednesday, September 3, 2003, at 05:40 AM, Christos Zoulas wrote:
> I don't think that it is a good idea to keep the sigcontext/sigreturn
> signal handling around. It is only needed for compatibility code now,
> and maintaining two signal code paths is just more work.
What you're saying is that you want to completely remove the
traditional BSD signal interface. Compatibility with the "old way" is
why there is an SA_SIGINFO flag, in the sigaction struct, right?
I don't see how it is so hard to provide support for both
sigcontext-type and siginfo-type handlers -- MI code works completely
with ksiginfo_t, and it is only converted to sigcontext at the last
possible moment by MD code.
> | I intended the ABI version to be within the domain of the trampoline
> | type. So, "sigcontext"-type handlers have one ABI domain, and
> | "siginfo"-type handlers have another ABI domain.
> I think that checking one number, is a lot easier than checking both a
> number and a flag and then maintaining two sets of ABI's. I really want
> to get rid of the old sigcontext code, since it is not portable across
> architectures and does not provide enough information about the signal
> cause to userland.
Well, if you didn't like it, I wish you would have voiced your
objection to the trampoline naming convention when I proposed it (along
with userland trampolines) ... quite some time ago. The scheme I
intended has been implemented and, more importantly, *documented* for
over a year now. See signal(9).
> I will fix gdb, but as I said above, I don't want to maintain two
Well, you sort of HAVE to, to be compatible with old binaries, right?
It's not like the two totally different paths through the kernel will
be taken... all you need to do is construct the correct context
structure for the trampoline right before you invoke the handler.
-- Jason R. Thorpe <firstname.lastname@example.org>