On Mon, 2012-01-30 at 12:31 +0100, Ingo Molnar wrote: > * Peter Zijlstra <[email protected]> wrote: > > > On Mon, 2012-01-30 at 11:11 +0100, Ingo Molnar wrote: > > > So, what workflow are you suggesting to Andrew? > > > > Librarize perf record, then in your code do something like: > > > > #include "perf_record.h" > > Maybe. (and then it shouldnt be limited to perf_record.h but > should be events.h plus libevents.so or such)
Yes it should be, you want to reserve the more generic name for less narrow interfaces. > > > > handle = perf_record_init(); /* creates perf events and creates > > a record thread that writes samples > > to perf.data, consumes env(PERF_*) > > for configuration, registers with > > at_exit() for cleanup */ > > if (!handle) > > /* burn */ > > > > /* do you other code */ > > > > perf_record_start(handle); > > > > /* do the bit you want profiled */ > > > > perf_record_stop(handle); > > > > Then build with -lperfrecord or so. Not too hard, right? > > Isnt a simple prctl() so much easier and faster? I really don't want to add another two prctl()s for this, ideally I'd remove the ones we have now, but I've never done due to maintaining backwards blah.. > 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, 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. -- 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
