On Fri, Aug 07, 2009 at 02:19:10PM -0700, Piet Delaney wrote:
Roland McGrath wrote:
Only a few arch's overload -ptrace for private purposes, and I don't
foresee any problem getting those fixed up soon. (The parisc maintainer is
doing it already. I think xtensa might have something on deck.
Roland McGrath wrote:
Only a few arch's overload -ptrace for private purposes, and I don't
foresee any problem getting those fixed up soon. (The parisc maintainer is
doing it already. I think xtensa might have something on deck. I can do
the arm changes if anybody will ever review and merge
I thought I check on xtensa having something on deck.
I'd like to test it if possible to avoid surprises and
if it's not ready, and needs to be, then to include this
while submitting SMP changes in the not too distant future.
Sorry, that was a dim recollection of mine and it appears to have
On Tue, Aug 04, 2009 at 06:09:11PM -0700, Roland McGrath wrote:
I agree, CONFIG_UTRACE_PTRACE should die. But what about !CONFIG_UTRACE
case? What should we do with arches which doesn't use tracehooks or
play with ptrace internals?
AIUI hch wants to have ptrace rely on utrace. Those
On 08/03, Roland McGrath wrote:
So. For the first version of CONFIG_PTRACE_UTRACE I'd suggest to use
-ptrace to keep the single bit, PT_PTRACED (well, PT_PTRACE_CAP too).
All other PT_ bits should go into engine-data.
Ok.
Actually the very first for utrace-devel only version should be
Actually the very first for utrace-devel only version should be just
your utrace-ptrace.patch + attach/detach fixes. Not that I can verify
this, but I hope that ptrace_utrace_ops's methods are more or less right.
(but of course, we should recheck them as much is possible).
The utrace_ops
On 07/24, Roland McGrath wrote:
For example, wait_consider_task(). Even some tracehooks, say,
tracehook_notify_death() need task_is_ptraced().
Not some, just that one, right?
Not just one. tracehook_tracer_task, tracehook_notify_jctl.
But,
So these are all really the same one
thing:
Not some, just that one, right?
Not just one. tracehook_tracer_task, tracehook_notify_jctl.
Ah. tracer_task is an outlier we can think about separately a little
later. The notify_jctl case is another in the same bag of wait/SIGCHLD
things that I had in mind.
The problem is, I can't
