* Peter Zijlstra <[email protected]> wrote:
> > What's your concern with the prctl()? This would arguably be
> > the right kind of usage for prctl(): it's an established
> > API/ABI for process/task-wide settings.
>
> Its doing things backwards, [...]
What does that mean?
> [...] also the whole concept of allowing people to hide things
> from a profiler is so rotten I'm not willing to even consider
> the notion.
But what we want here is not to hide things from the profiler,
what we want to be able to is to *ask* the profiler to hide
things for us, and we do that for a good reason.
This distinction (which I agree is important) could be
implemented by adding a "allow self-profiling" bit (default
disabled) in the perf_attr. That way such code would not be able
to 'hide' from a simple:
perf top
perf record -a
session, but would be able to self-profile from such a session:
perf record --allow-self-profile ...
where there could be some easy shortcut for
--allow-self-profile, such as:
perf record -S
that way no code could ever hide from a profiler, only if the
profiler is specifically allowing self-profiling. (opt in)
The librarization you suggested might make sense too - but i
think people will gravitate towards the easier to use variant,
and prctl() is as easy and straightforward as it gets.
We can Cc: it to Linus with an explicit [RFC] and he can shoot
it down if the API is ugly - but I don't think it's ugly.
Hm?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
