Pour ne plus recevoir de courriels de notre part, il vous suffit de vous rendre sur cette page.
On 11/23, Srikar Dronamraju wrote:
I don't have a powerpc machine, but I think this test-case should
see the difference:
On a powerpc machine, I did verify that the below test-case differs with
your patch. Without the patch it would print the message
kernel bug: status=857F shouldn't have
On 11/22, Roland McGrath wrote:
Perhaps we should send 8-10 to akpm right now?
I'm not sure whether that would more useful. It's really up to you.
IMHO those are not standalone cleanups like 2-7 (and even 1) are.
So to me it
makes more sense to have those travel as part of that whole
At this URL find built rpms (x86_64 and i686 only) that you can install on
a Fedora 12 (or rawhide, probably) system. These are the upstream kernel
du jour with the current utrace-ptrace branch code (see rpm changelog for
commit id). (I tried an f12-flavored build too, but it looks like the
No need to to use different ENTRY/EXIT syscall codes any longer.
PTRACE_EVENT_SYSCALL_EXIT was introduced to emulate send_sigtrap()
from syscall_trace_leave(), now we don't do this.
---
kernel/ptrace-utrace.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
On 11/18, Roland McGrath wrote:
In any case, what is the rationality?
The rationale is that if you see utrace_resume_action(action)==UTRACE_STOP
in your callback, then you know another engine asked for stop
Yes, but engine can't know if the next one is going to return
UTRACE_STOP.
