On 08/30, Roland McGrath wrote: > > > Signals. ptrace processes a signal after all other attached engines. > > As my reply to that patch indicated, what you can given the > tracehook_get_signal API does not really fit that description.
Yes. > Perhaps by ignoring signr and looking at si_signo you could > call it almost that. But still it's questionale. Yes. And the usage of "ka" is buggy. Perhaps more or less solveable, but questionale. > > Why? 2.6.32 is close. I doubt I can make the full-blown (and _working_) > > implementation before the merge window. And I am nervous because I doubt. > > I share your concerns. But all we can do is try to produce things that > really will get merged. If you are convinced that efforts on this new > temporary kludge approach for ptrace make the difference in getting the > utrace core merged into 2.6.32, then go for it. That seems unlikely to me, Now this seems unlikely to me too. I had to do a lot of testing on Sunday before I was able to realize we have other issues. For example, utrace_reset() clears TIF_SYSCALL_TRACE. Again, looks fixeable, but uglifies this kludge even more. Oleg.
