[PATCH v6 00/14] uprobes: Add uprobes support for ARM
srikar at linux.vnet.ibm.com
Mon Mar 3 01:23:24 EST 2014
> I've been looking at arch/Kconfig and kernel/trace/Kconfig where
> they deal with uprobes. The relevant items are CONFIG_UPROBES and
> CONFIG_UPROBE_EVENT. It just doesn't look right to me. It looks
It should be me who should take the blame for this and not Oleg. This
was discussed more than couple of times. I can recollect couple of
I know there were more discussions on this, but I cant dig them out at
this time. Finally it was decided that
1. Users shouldnt have to select more than one config to select Uprobes.
2. There was no point in selecting Uprobes and not having Uprobe_event
and vice versa.
>From the above, If a user chose UPROBE_EVENT, (which is the interface
for uprobes), we would automatically assume that he wants to use Uprobes
> like "select" is used in part maybe just to avoid the recursive
> dependency error that would be generated if "depends on" were used
> in both places.
We did "Select Uprobes" not because of avoiding recursive dependency but
as told above, to select the framework, given that user has chosen the
framework. We dont want to give a choice to user to choose uprobe_event
but not choose Uprobes or vice versa.
> However I don't think UPROBES should be dependent on
> UPROBE_EVENT, only the other way around. As RK noted in previous
Whats the point of having the framework(Uprobes) without an interface?
> email (copied in part below) the select does not pull in the lower
> level dependencies. This all works on x86 only because
> arch/x86/Kconfig defines CONFIG_PERF_EVENT (which feels like a big
> hammer). We don't need to do this on ARM, and we don't do it. The
> result is that, unless PERF_EVENT is set separately, uprobes tends
> not to build. I was lucking-out in my testing due to other default
> config items turning on PERF_EVENT.
Thanks and Regards
More information about the linux-arm-kernel