Messages in this thread | | | Date | Mon, 2 Aug 2010 09:58:15 +0200 | From | Frederic Weisbecker <> | Subject | Re: [PATCHv10 2.6.35-rc6-tip 9/14] trace: uprobes trace_event interface |
| |
On Mon, Aug 02, 2010 at 12:16:38PM +0530, Srikar Dronamraju wrote: > > > > > > 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'd like to suggest below config tree > > > > Kenrel hacking > > - Kprobes > > - Uprobes > > - Tracing > > -- Dynamic Events > > depends on Kprobes || Uprobes > > or > > select Kprobes && Uprobes > > I would agree with Masami since there could be people who might be > apprehensive to try out Uprobes (which would still be experimental) but > would be interested to use kprobes only since its more mature. > > One change I would suggest would be to select respective events(i.e > kprobe_event, uprobe_event) instead of kprobes and uprobes.
Yeah sure. The goal was to still have both selectable independently, but have a menu that can select all in one.
ie:
config DYNAMIC_PROBE depends on (KPROBES || UPROBES) && EVENTS_TRACING default n
config KPROBES_EVENT: depends on DYNAMIC_PROBE && KPROBES default y
config UPROBES_EVENT: depends on DYNAMIC_PROBE && UPROBES default y
So that people who want dynamic probes just don't care and select dynamic probe. Those who want more granularity can still unselect uprobes events or kprobes events after that.
| |