On 03/03/14 01:23, Srikar Dronamraju wrote:
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
discussions here.
http://article.gmane.org/gmane.linux.kernel/1017186
http://article.gmane.org/gmane.linux.kernel/1001605
I wasn't trying to assign blame to anyone, I was just soliciting an
opinion from the last uprobes maintainer I had a conversation with.
Thanks for the links.
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
framework.
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.
I suppose that's more to the point.
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?
My comment was based only in the fact it built successfully that way on
both x86 and ARM. If there's no way to access the functionality without
both selected then I suppose it does make sense to not allow that
configuration. Maybe it's time to remove one of these config symbols.
I didn't see anything in the email history on this that says that would
be a bad idea. I'll try and come up with a patch.
-dl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
