linux-kernel - Re: [PATCH 13/14] tools lib fd array: Allow associating an integer cookie with each entry

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:	Thu, 11 Sep 2014 12:23:30 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Jiri Olsa <jolsa@...hat.com>
Cc:	linux-kernel@...r.kernel.org,
	Adrian Hunter <adrian.hunter@...el.com>,
	Borislav Petkov <bp@...e.de>,
	Corey Ashford <cjashfor@...ux.vnet.ibm.com>,
	David Ahern <dsahern@...il.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...nel.org>,
	Jean Pihet <jean.pihet@...aro.org>,
	Jiri Olsa <jolsa@...nel.org>,
	Namhyung Kim <namhyung@...nel.org>,
	Paul Mackerras <paulus@...ba.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH 13/14] tools lib fd array: Allow associating an integer
 cookie with each entry

Em Thu, Sep 11, 2014 at 04:59:45PM +0200, Jiri Olsa escreveu:
> On Thu, Sep 11, 2014 at 10:29:11AM -0300, Arnaldo Carvalho de Melo wrote:
> > But then I had no use whatsoever for the ->ptr one at this point, so I
> > just nuked it, to keep _just_ what is used _right now_, and added the
> > comment to the changelog :-)
> 
> if we are treeting tools/lib/api as 'external' lib, I think we should
> use 'void *' for priv and let the user retype it to whatever he wants
 
> but I dont care/insist here too much.. it just seems strange to me ;-)

Ok, so perhaps it should be:

	struct fdarray {
		...
		union {
			int idx;
		} *priv;
		...
}

And then perf's evlist will use:

	fda->priv[fd].idx;

	Then, when we get the need for a pointer, we can go there and
add it to the union.

	This will make tools/lib/api/fd/ a little bit more friendly to
use outside the kernel sources, since then a new version will be source
code compatible (but not necessarily binary compatible).

	If we commit to that we can't just go on and change all its
users as we can now do for things like 'struct sk_buff', 'struct sock'
and any other kernel data structures.

	There are costs in making it 'external' in the sense you're
implying. I want to make it a bit less 'external' (in your sense), at
least while we initially implement new stuff like this one.

	My preference is for us to move things to tools/lib/ and
initially support use of it for tools that live in the kernel sources.

	If and when people find it useful for things outside the kernel
sources, if we think that the code is perfect (ha ha) we can add some
comment saying that that particular source file can't be changed in a
way that will break out-of-the-kernel-tree sources.

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