On Sep 3,  7:59am, thorpej@wasabisystems.com (Jason Thorpe) wrote:
-- Subject: Re: SA_SIGINFO patch

| 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 think so; SA_SIGINFO appeared with svr4 at the same time
with get/setcontext and the signal handlers were converted at that
point to use ucontext. To keep using sigcontext, means that we still
need to keep sigreturn() around. That is only enabled with COMPAT_16
right now.

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

Yes, but there is no clean and portable way of using sigcontext, since it
varies between architectures. New code should not be using sigcontext
anymore.

| 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 did not think about it at the time. I don't particularly care which
way it is done, I am just saying that it is more complicated to do the
version checking in the kernel the way you suggest. If you are married
to that way, I'll change the code to do the song and dance for the version
check. I don't see the advantage though.

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

Right. And the old way is still there. The new way [ucontext] is almost
there for the remaining archs. Most of the conversion work is in the trap
glue.

christos