mv kernel/ptrace.c kernel/ptrace-utrace.c.
Then I will send the patch which restores the old ptrace.c and
moves kernel/ptrace-common.h into it as you suggested before.
I am not sure what is the best way to do these renames but I hope
this doesn't really matter, utrace-ptrace branch is only for
On 11/18, Roland McGrath wrote:
So maybe you will look at this and merge them before I do.
Whatever we do, perhaps it makes sense to apply your patch
in https://www.redhat.com/archives/utrace-devel/2009-November/msg00109.html
first and then do further changes?
This way we will have the working
The former is e.g. PTRACE_SINGLESTEP while an unrelated engine uses
UTRACE_EVENT(SYSCALL_ENTRY). The ptrace engine's report_quiesce returns
UTRACE_SINGLESTEP. finish_resume_report() calls user_enable_single_step().
That seems fine. Right?
In this case ptrace_report_quiesce(event)
I am not sure what is the best way to do these renames but I hope
this doesn't really matter, utrace-ptrace branch is only for us.
Sure, whatever you want to try is fine.
The goal is to make it testable with and without CONFIG_UTRACE.
Ok. We need to get upstream feedback on what they do or
Whatever we do, perhaps it makes sense to apply your patch
in https://www.redhat.com/archives/utrace-devel/2009-November/msg00109.html
first and then do further changes?
Ok. v2.6.32-rc8-245-g3d4f9cf has that. I'll shelve this 4-patch series
while we keep discussing (one more reply to come
Somehow I can't really understand this patch. I hope more or less
I can see what it does, but the resulting code looks even more
subtle to me.
Well, it was an untested draft and probably needed more comments.
With this patch, apply_resume_action() is always called after
utrace_stop(). Well,
