Re: [RFC, PATCH 0/2] utrace/ptrace: simplify/cleanup ptrace attach

[Christoph Hellwig]

On Wed, May 06, 2009 at 10:12:25AM +0200, Ingo Molnar wrote:
> Yes. But realize the fundamental reason for that: _without_ 
> ptrace-over-utrace the utrace core code is a big chunk of dead code 
> only used on the fringes. I see and agree with all the future uses 
> of utrace, but it's easy to be problem-free if a facility is not 
> used by anything significant.

The ptrace cleanups might be required for utrace, but they by
themselves don't make utrace any more useful without another
user.

> So a clean ptrace-over-utrace plugin is absolutely needed for utrace 
> to go upstream in v2.6.31. The ftrace plugin alone does not justify 
> it. The real prize here is a (much!) cleaner ptrace code. Once 
> ptrace is driven via utrace and it works, its value (and trust 
> level) will skyrocket.

There are two blockers for utrace:

 - first all architectures need to be converted to the ptrace world
   order with regsets, tracehooks and so on.  I hope we are on track
   to get this done now after I've pinged all arch maintainers.
 - we actually need a useful user of the utrace abstraction.  And just
   converting ptrace to make it slightly more complicated by using
   another abstraction just isn't it.  One useful bit that is in the
   queue is a in-kernel gdbstub for user process which would allow
   to get out of the ptrace and re-parenting mess for basic use
   cases.  But a really convincing user would be even better.

I don't think 2.6.31 is a very realistic target.  While a lot of arch
maintainers are working on their ptrace code 2.6.31 is just a too short
deadline, and I'm also not sure we'll have the ptrace code in shape
by then.  2.6.32 is much more realistic.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/