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

[Arnaldo Carvalho de Melo]

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