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 
> signal
> paths.

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.

>
> christos
>
         -- Jason R. Thorpe <thorpej@wasabisystems.com>