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
> 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 hav
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
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. Tho
> 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 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
> > 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
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
>