From: Ingo Molnar <mingo@elte.hu>
To: Albert Cahalan <acahalan@gmail.com>
Cc: torvalds@osdl.org, ak@suse.de, alan@lxorguk.ukuu.org.uk,
arjan@infradead.org, bunk@stusta.de, akpm@osdl.org,
rlrevell@joe-job.com, linux-kernel@vger.kernel.org,
Roland McGrath <roland@redhat.com>
Subject: Re: utrace vs. ptrace
Date: Thu, 13 Jul 2006 09:04:45 +0200 [thread overview]
Message-ID: <20060713070445.GA30842@elte.hu> (raw)
In-Reply-To: <787b0d920607122243g24f5a003p1f004c9a1779f75c@mail.gmail.com>
* 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
next prev parent reply other threads:[~2006-07-13 7:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-13 5:43 [patch] let CONFIG_SECCOMP default to n Albert Cahalan
2006-07-13 7:04 ` Ingo Molnar [this message]
2006-07-13 9:24 ` utrace vs. ptrace Ingo Molnar
2006-07-13 12:37 ` Andi Kleen
2006-07-13 12:43 ` Ingo Molnar
2006-07-13 13:21 ` Andi Kleen
2006-07-13 13:28 ` Arjan van de Ven
2006-07-13 13:34 ` Andi Kleen
2006-07-13 13:37 ` Arjan van de Ven
2006-07-13 13:46 ` Andi Kleen
2006-07-13 19:05 ` Linus Torvalds
2006-07-13 19:47 ` Ingo Molnar
2006-07-14 10:42 ` Paul Jackson
2006-07-25 18:49 ` Alan Cox
2006-07-25 18:27 ` Linus Torvalds
2006-07-25 18:57 ` Olaf Hering
2006-07-25 19:12 ` Ingo Molnar
2006-07-26 0:20 ` Martin Bligh
2006-07-13 7:07 ` [patch] let CONFIG_SECCOMP default to n andrea
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060713070445.GA30842@elte.hu \
--to=mingo@elte.hu \
--cc=acahalan@gmail.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjan@infradead.org \
--cc=bunk@stusta.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rlrevell@joe-job.com \
--cc=roland@redhat.com \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox