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

[Robert Richter]

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_ATTACH (Since Linux 3.xx)
> > > PERF_EVENT_IOC_DETACH (Since Linux 3.xx)
> > 
> > I think these aren't very good names for the ioctls.  Maybe something
> > like
> >   PERF_EVENT_IOC_MAKE_PERSISTENT
> >   PERF_EVENT_IOC_UNPERSIST
> > I know that last one's not a real word but I can't think of what the 
> > proper term would be.  Maybe
> >   PERF_EVENT_IOC_RELEASE_PERSISTENT
> >   PERF_EVENT_IOC_RECLAIM_PERSISTENT
> 
> "aren't very good names" is not really an argument I can work with. Why
> not? What if you want to attach/detach to events but not be persistent.
> Which also begs the question how long are we persistent? The whole
> system runtime or until the user decides to detach.
> 
> So ATTACH/DETACH in the sense of attaching processes to events for an
> arbitrary amount of time *and* *not* for the duration of the tracee
> as we do it currently implicitly, is much more generic wrt usage than
> specifying that specific persistent case.

Ok, for clarification, my intention was to say something like 'detach
event from the current process controlling it', or 'attach the event
to the current process that holds the fd'.

Whatever term is the best for this ioctls, I am fine with it. The
above terms look a bit long.

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.

-Robert
--
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/