On Fri, 23 Aug 2013, Borislav Petkov wrote: > On Fri, Aug 23, 2013 at 12:44:41PM +0200, Robert Richter wrote: > > On 23.08.13 11:45:56, Robert Richter wrote: > > > On 23.08.13 11:11:28, Borislav Petkov wrote: > > > > On Thu, Aug 22, 2013 at 02:18:06PM -0400, Vince Weaver wrote: > > > > > PERF_EVENT_IOC_MAKE_PERSISTENT > > > > > PERF_EVENT_IOC_UNPERSIST > > > > Maybe this? > > > > PERF_EVENT_IOC_PERSIST > > PERF_EVENT_IOC_UNPERSIST > > No, ATTACH/DETACH actually describes what you do with the fds and is > most generic. "PERSIST*" is a special use case of attaching/detaching > events.
I agree with what Robert said elsewhere in this thread: "The problem with detach/attach is more that it's actually more logically to attach first and afterwards detach. This is not the case here, it's vise versa." My main confusion is that with some other performance tools, such as PAPI, "attach" specifically means to take an event and attach it to a process (much like the -p option to strace or gdb) or a cpu. Now perf_event handles this differently (you do that at open time) but I still think it gets things backwards. Since ATTACH is usually a transitive verb in English I'd think the name should specify what two things are being attached. If I had not read the man-page fragment and saw a result=ioctl(fd,PERF_EVENT_IOC_ATTACH,0); I'd have no clue what it was doing (attach? attach to what?) wheras if I saw result=ioctl(fd,PERF_EVENT_IOC_UNPERSIST,0); it's a little more clearer and also indicates that the ioctl is only valid if you're dealing with a persistent event. Vince -- 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/
