Re: [PATCHv10 2.6.35-rc6-tip 9/14] trace: uprobes trace_eventinterface

[Ingo Molnar]

* Frederic Weisbecker <fweisbec@xxxxxxxxx> wrote:

> On Mon, Aug 02, 2010 at 12:45:08PM +0900, Masami Hiramatsu wrote:
> > Frederic Weisbecker wrote:
> > > On Thu, Jul 29, 2010 at 02:04:14PM +0900, Masami Hiramatsu wrote:
> > >> Srikar Dronamraju wrote:
> > >>> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> > >>> index c681fa7..16e2a8c 100644
> > >>> --- a/kernel/trace/Kconfig
> > >>> +++ b/kernel/trace/Kconfig
> > >>> @@ -482,6 +482,22 @@ config RING_BUFFER_BENCHMARK
> > >>>  
> > >>>  	  If unsure, say N.
> > >>>  
> > >>> +config UPROBE_EVENT
> > >>> +	bool "Enable uprobes-based dynamic events"
> > >>> +	depends on ARCH_SUPPORTS_UPROBES
> > >>> +	depends on MMU
> > >>> +	select UPROBES
> > >>> +	select PROBE_EVENTS
> > >>> +	select TRACING
> > >>> +	default n
> > >>> +	help
> > >>> +	  This allows the user to add tracing events on top of userspace dynamic
> > >>> +	  events (similar to tracepoints) on the fly via the traceevents interface.
> > >>> +	  Those events can be inserted wherever uprobes can probe, and record
> > >>> +	  various registers.
> > >>> +	  This option is required if you plan to use perf-probe subcommand of perf
> > >>> +	  tools on user space applications.
> > >>> +
> > >> Possible enhancement: Moving this config right after KPROBE_EVENT, because
> > >>  those two provide similar dynamic events.
> > >>
> > >> Thank you,
> > > 
> > > 
> > > In fact this could be a menu "Dynamic Probes", perhaps default off, inside
> > > which Kprobes and Uprobes would be default on (but depend on "Dynamic Probes").
> > > 
> > > So that you can quickly enable them all in one.
> > 
> > Hmm, I disagree with it, because both Kprobes and Uprobes provides
> > APIs for modules too.
> 
> I'm not sure there is a point in maintaining a leightweight version for out 
> of tree code. These modules could just select kprobes/uprobes events as 
> well.
> 
> As you prefer, that was just a suggestion to make it more simple.

The upstream policy always was that out of tree code does not exist as far as 
the kernel is concerned. So it is wrong to make the kernel crappier while 
helping out of tree code.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/