Re: utrace vs. ptrace

[Ingo Molnar <mingo@elte.hu>]

* Albert Cahalan <acahalan@gmail.com> wrote:

> The utrace stuff offers some hope for eventually fixing this mess. 
> Please accept that or something similar.

yeah. Much of the API and usage problems of ptrace stem from its (mostly 
artificial) coupling to signals (and other, mostly historical baggage).

utrace gets rid of all of that baggage and artificial coupling! The 
utrace patchset first rips out all of ptrace (completely!), then adds 
utrace (which is in essence the CPU state fiddling bits of ptrace), then 
adds the ptrace API as an utrace module. It really doesnt get cleaner 
than that. See:

  http://people.redhat.com/roland/utrace/0-intro.txt

and:

  http://people.redhat.com/roland/utrace/

for the actual code.

utrace enables exciting things like a global crash-handling daemon that 
can collect live info from crashing (segfaulting) apps transparently, 
_without_ having all apps in the system ptraced in advance!

One of the biggest QA problems Linux has is that we very frequently lose 
information about the 'first incidence of crashing'. [Some of the GUIs 
have automatic crash-reporting, but those solutions are obviously 
limited to those GUIs and they dont use ptrace and have various 
shortcomings.]

utrace enables something like 'transparent live debugging': an app 
crashes in your distro, a window pops up, and you can 'hand over' a 
debugging session to a developer you trust. Or you can instruct the 
system to generate a coredump. Or you can generate a shorter summary of 
the crash, sent to a central site.

utrace enables the distro to automatically (and transparently) download 
debuginfo packages of an app that segfaults so that next time the crash 
happens there's better info to debug it - without the user having to 
bother about this.

utrace enables multiple debugging infrastructures being attached to the 
same task.

and last but not least, utrace enables the prototyping of debuging 
infrastructure without having to revamp the kernel APIs all the time.

Even if i wanted i couldnt over-hype utrace: it is by far the most 
important thing that happened to ptrace (and Linux debugging in general) 
in the past 10 years or so.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/