Re: linux-next: add utrace tree

[Ananth N Mavinakayanahalli]

On Sat, Jan 23, 2010 at 12:23:33PM +0100, Ingo Molnar wrote:
> 
> * Kyle Moffett <kyle@xxxxxxxxxxxxxxx> wrote:
> 
> > On Fri, Jan 22, 2010 at 19:22, Linus Torvalds
> > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
 
...

> In that sense it might be better to fix/enhance ptrace, if there's interest. 
> I've written a handful of ptrace extensions in the past (none of them went 
> upstream tho), it can be done in a useful manner and the code is pretty 
> hackable. There are basic problems left to be solved: for example why is there 
> still no 'memory block copy' call, why are we _still_ limited to one word per 
> system call PTRACE_PEEK* memory copies? It's ridiculous. SparcLinux has 
> PTRACE_WRITE*/READ* support that implements this, but none of the other 
> architectures have it so it's essentially unused.
> 
> Or another possible direction would be to extend the perf events syscall with 
> interception capabilities. It's far more performant at extracting application 
> state without scheduling than any ptrace method - and interception/injection 
> would be a natural next step - if there's interest.

This certainly is now a chicken and egg problem. Everybody agrees that
Linux needs something better than ptrace; legacy ptrace will continue to
live, so will utilities written to it (strace, etc).

But should that limit what Linux can offer? What's the way out?

- Enhance ptrace: At least one ptrace maintainer (Roland) had publically
  stated he doesn't prefer enhancing legacy ptrace -- that its already a
  beast to maintain, and adding more complexity to it does it no good.

- Extend perf; would perf then use utrace underneath? Or would one have
  to redo some of what utrace already does for thread level control?

- Give utrace a syscall and make it the primary way for users to
  interact with the layer. There are benefits to this if there is
  agreement on the utrace layer itself, maybe with less fexibility than
  what it currently offers? If yes, what should it look like?

Any new debug facility will have to incorporate some or most learnings
from what utrace tried to address. It would be sad to just dump utrace
and redo everything from scratch or band-aid existing interfaces.

Ananth
--
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/