linux-kernel - Re: [PATCH v3 12/12] [RFC] perf, persistent: ioctl functions to control persistency

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 23 Aug 2013 11:45:56 +0200
From:	Robert Richter <rric@...nel.org>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Vince Weaver <vince@...ter.net>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Jiri Olsa <jolsa@...hat.com>, linux-kernel@...r.kernel.org,
	Vince Weaver <vincent.weaver@...ne.edu>
Subject: Re: [PATCH v3 12/12] [RFC] perf, persistent: ioctl functions to
 control persistency

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