[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100129091646.GC10878@elte.hu>
Date: Fri, 29 Jan 2010 10:16:46 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Ananth N Mavinakayanahalli <ananth@...ibm.com>
Cc: Jim Keniston <jkenisto@...ibm.com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Kyle Moffett <kyle@...fetthome.net>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Fr??d??ric Weisbecker <fweisbec@...il.com>,
Oleg Nesterov <oleg@...hat.com>,
Steven Rostedt <rostedt@...dmis.org>,
LKML <linux-kernel@...r.kernel.org>,
Tom Tromey <tromey@...hat.com>,
"Frank Ch. Eigler" <fche@...hat.com>, linux-next@...r.kernel.org,
"H. Peter Anvin" <hpa@...or.com>, utrace-devel@...hat.com,
Linus Torvalds <torvalds@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: linux-next: add utrace tree
* Ananth N Mavinakayanahalli <ananth@...ibm.com> wrote:
> On Fri, Jan 29, 2010 at 01:22:40PM +0530, Ananth N Mavinakayanahalli wrote:
> > On Fri, Jan 29, 2010 at 08:39:07AM +0100, Ingo Molnar wrote:
> >
> > ...
> >
> > > When we merged kprobes ~10 years ago we made the (rather bad) mistake of
> > > merging a raw, opaque facility and leaving 'the rest' up to some other entity.
> > > IBM kprobes hackers vanished the day the original kprobes code went upstream
> > > and the high level entity never truly materialized in-kernel, for nearly a
> > > decade!
> >
> > I don't know what you are referring to here... Kprobes was merged in
> > 2.6.9 (~August 2004 -- less than 6 years ago). Since then, we did work
> > on ports to powerpc and s390. We implemented kretprobes. We made it much
> > scalable using RCU; we did the powerpc booster to skip single-step when
> > possible, not to mention various bug fixes over the years.
> >
> > Yes, we did not do the perf integration, but perf did not exist then, either.
> >
> > Its simply wrong to say people 'vanished'.
>
> Oh, and the x86 instruction decoder was initially implemented by us.
Which he implemented at my suggestion, to make it safe and robust for 'perf
probe' even if debuginfo for some reason gives us the wrong address and we try
to insert a probe where we shouldnt.
> Masami has done a great job making it more complete.
Absolutely and certainly so! I'm not talking about the present - i'm happy
about where kprobes is going currently, and the new jump-probes optimizations
look promising too.
I just see uprobes repeating some of the mistakes of early kprobes, and i want
us to learn from that experience. In my experience real usage and good
integration is the key to that, and we can skip those lost 5 years.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists