lkml.org 
[lkml]   [2009]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC, PATCH 0/2] utrace/ptrace: simplify/cleanup ptrace attach
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.


\
 
 \ /
  Last update: 2009-05-06 10:25    [W:0.031 / U:24.416 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site