Re: [PATCH v3 12/12] [RFC] perf, persistent: ioctl functions tocontrol persistency

[Vince Weaver]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/