[PATCH 3/3] utrace-based ftrace "process" engine, v2

[Ingo Molnar]

* Andrew Morton <akpm at linux-foundation.org> wrote:

> On Sat, 21 Mar 2009 08:43:01 +0100 Ingo Molnar <mingo at elte.hu> wrote:
> 
> > 
> > * Roland McGrath <roland at redhat.com> wrote:
> > 
> > > From: Frank Ch. Eigler <fche at redhat.com>
> > > 
> > > 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 layer.  This new patch interfaces 
> > > many of those events to ftrace, as configured by a small number of 
> > > debugfs controls.  Here's the 
> > > /debugfs/tracing/process_trace_README:
> > 
> > Please submit changes/enhancements to kernel/trace/* to the tracing 
> > tree maintainers (Steve and me) for review, testing and integration.
> > 
> > Please also post patches against the latest tracing tree:
> > 
> >    http://people.redhat.com/mingo/tip.git/README
> 
> uhm, this patch depends on the (large) utrace patch, which is not 
> kernel/trace material.

The thing is, utrace crashes in Fedora have dominated kerneloops.org 
for many months, so i'm not sure what to make of the idea of posting 
a 4000+ lines of core kernel code patchset on the last day of the 
development cycle, a posting that has carefully avoided the Cc:-ing 
of affected maintainers ;-)

Utrace is very much tracing material - without the ftrace plugin the 
whole utrace machinery is just something that provides a _ton_ of 
hooks to something entirely external: SystemTap mainly.

kernel/utrace.c should probably be introduced as 
kernel/trace/utrace.c not kernel/utrace.c. It also overlaps pending 
work in the tracing tree and cooperation would be nice and desired.

The ftrace/utrace plugin is the only real connection utrace has to 
the mainline kernel, so proper review by the tracing folks and 
cooperation with the tracing folks is very much needed for the whole 
thing.

	Ingo