> No functional changes, preparation. I don't see how this helps prepare for anything in particular. When this path is really relevant at all, we'll just remove ptrace_signal.
> Change get_signal_to_deliver() so that ptrace_signal() is called even > if utrace returns signr != 0. > > I think this is more correct now, when ptrace is not implemented on > top of utrace. I don't think so. The return value from tracehook_signal is not a real signal, it's a representative signal directing a specific disposition. If there were both utrace and old ptrace coexisting today, it would be wrong to have ptrace intercept the results of utrace_get_signal. > When we change ptrace to use ->report_signal() ptrace_signal() should > be killed/ifdefed anyway, so afaic this change will not interfere with > utrace-ptrace. There is no other reason to touch this code at all. I don't see any motivation for this patch. Thanks, Roland
