Re: [PATCH 29/66] tools lib traceevent: Use str_error_r()

[Arnaldo Carvalho de Melo]

Em Wed, Jul 13, 2016 at 08:30:01AM -0400, Steven Rostedt escreveu:
> On Tue, 12 Jul 2016 20:32:18 -0300
> Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> wrote:
> > > > Forgot about the out of tree copy :-\  

> > > Yeah, we really need to make this into a real library. I haven't had
> > > the time to do that. Hopefully in August I can talk with some people at  

> > What exactly do you mean by that? To grab a copy of what is in tools/
> > and have it turned into a library somewhere else?

> > Or to freeze its interfaces and create an .so with a committed to ABI?

> Yes, this is what we need to do.

> > I kind of like the way it is now... :-)

> You like the current ABI? Or the fact that we have 4 tools with each

I like the lack of an ABI, i.e. I like to use the same rationale for
when a out of tree driver breaks because we improve kernel internals. As
soon as we commit to an ABI for those libraries, that becomes way more
difficult.

And since we're still adding more and more stuff (write_backward, eBPF
for kernel and userspace, etc, etc) I fear lots are still very much in
flux to commit to something like that.

So if we know what are the needs of those out of the tree tools (can't
they be brought in tree? I'm digressing, couldn't resist, sorry ;-)),
then we could, if absolutely required, try, without much enthusiasm,
relutanctly, see what could be done besides what has been already
underway (moving stuff out of tools/perf and into tools/lib).

It would add more burden to me for perhaps reducing the burden to who
would use those libraries.

> their own copies of the library? (and maybe even more)

Which ones?

- Arnaldo
 
> > > LinuxCon to see the best way to go about doing that.

> > > Anyway, I may just take that file and port it to trace-cmd.  

> > Yeah, that would solve this specific case.

> OK, I'll do this.