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 either get no ptrace
> (we cond_syscall it) and/or just stop building if not updated.  Maybe he
> can give you some more direct advice about what the merging plan should be.
> 
> The tracehook conversion is pretty simple for every arch, even for non-arch
> people (if you just punt the syscall-abort support, which is a new feature
> and so a non-regressing incremental step).  

Really architectures should be converted, and it would help if someone
else could ping the outstanding architectures again.  At some point if
they are few enough  we can just break them.

> > Firstly, these changes can't be applied until we fix arch/ which play
> > with ->ptrace.
> 
> 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 them.)

Converting the architectures to tracehooks and new-style ptrace should
mostly take care of it like for parisc.

As for arm you might have to push it a bit more, it didn't seem like rmk
was very excited about your first set of patches.

Reply via email to