public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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