On Thu, 21 Jan 2010 19:51:47 -0500 "Frank Ch. Eigler" wrote:
> Hi -
>
> On Thu, Jan 21, 2010 at 04:31:45PM -0800, Andrew Morton wrote:
> > [...]
> > > Someone please sell this to us.
> > Here's what Oleg said last time I asked this: [...]
>
&
On Thu, 21 Jan 2010 16:30:04 -0800
Andrew Morton wrote:
> Someone please sell this to us.
Here's what Oleg said last time I asked this:
First of all, utrace makes other things possible. gdbstub,
nondestructive core dump, uprobes, kmview, hopefully more. I didn't
look at t
On Fri, 22 Jan 2010 11:17:47 +1100
Stephen Rothwell wrote:
> Any thoughts?
I'm nearly a week behind again and am trying to avoid thinking.
I've had a (n old) version of utrace in -mm for ages and it didn't
break anything.
I still don't think I've seen a really compelling reason for merging
it.
On Fri, 18 Dec 2009 02:11:16 +0100
Oleg Nesterov wrote:
> Hello.
>
> This is the new iteration of Roland's utrace patch, this time
> with "rewrite-ptrace-via-utrace" + cleanups in utrace core.
>
So... should we merge this?
I'll confess that I've rather forgotten why we might want this.
> It
On Wed, 29 Jul 2009 04:01:40 +0200
Oleg Nesterov wrote:
> (textually depends on signals-tracehook_notify_jctl-change.patch)
>
> Introduce the empty inline tracehook_finish_jctl() helper called by
> do_signal_stop() after wakeup.
>
> Currently we lack the ability to report this state change.
>
On Mon, 4 May 2009 12:43:48 -0700 (PDT)
Roland McGrath wrote:
> > > When those are on their way,
> > > we'll update the utrace patches not to conflict. I don't think it makes
> > > sense to include utrace.patch's little ptrace.c change in the baseline
> > > tree
> > > for your ptrace cleanup p
So we need to work out what to do about utrace and I feel a need to hit
the reset button on all this. Largely because I've forgotten
everything and it was all confusing anyway.
Could those who object to utrace please pipe up and summarise their
reasons?
Just to kick the can down the road a bit
On Tue, 24 Mar 2009 10:59:26 +0530 Ananth N Mavinakayanahalli
wrote:
> On Sat, Mar 21, 2009 at 05:04:22AM -0700, Andrew Morton wrote:
> > On Sat, 21 Mar 2009 07:51:41 -0400 "Frank Ch. Eigler"
> > wrote:
> > > On Sat, Mar 21, 2009 at 04:19:54AM -0700, An
On Sat, 21 Mar 2009 16:45:01 +0100 Ingo Molnar wrote:
>
> [...]
>
useful, thanks.
> Putting utrace upstream now will just make it more
> convenient to have SystemTap as a separate entity - without any of
> the benefits. Do we want to do that? Maybe, but we could do better i
> think.
It wou
On Sat, 21 Mar 2009 07:51:41 -0400 "Frank Ch. Eigler" wrote:
> Hi -
>
> On Sat, Mar 21, 2009 at 04:19:54AM -0700, Andrew Morton wrote:
> > [...]
> > > Utrace is very much tracing material - without the ftrace plugin the
> > > whole utrace machinery
On Sat, 21 Mar 2009 10:12:35 +0100 Ingo Molnar wrote:
>
> * Andrew Morton wrote:
>
> > On Sat, 21 Mar 2009 08:43:01 +0100 Ingo Molnar wrote:
> >
> > >
> > > * Roland McGrath wrote:
> > >
> > > > From: Frank Ch. Eigler
> >
On Fri, 20 Mar 2009 18:41:40 -0700 (PDT) Roland McGrath
wrote:
> This adds the utrace facility, a new modular interface in the kernel for
> implementing user thread tracing and debugging. This fits on top of the
> tracehook_* layer, so the new code is well-isolated.
>
> The new interface is in
On Sat, 21 Mar 2009 08:43:01 +0100 Ingo Molnar wrote:
>
> * Roland McGrath wrote:
>
> > From: Frank Ch. Eigler
> >
> > This is v2 of the prototype utrace-ftrace interface. This code is
> > based on Roland McGrath's utrace API, which provides programmatic
> > hooks to the in-tree tracehook
13 matches
Mail list logo
