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

[Steven Rostedt]

On Wed, 13 Jul 2016 10:51:25 -0300
Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> wrote:

> 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.

Yes, ABI is hard. But it can be done. Let's not get lazy. The code came
from external sources to begin with. I've been working hard to try to
keep the ABI fixed. There's still a few things I would like to change
before doing it officially, and that's because this code is quite
mature now, and I have an idea of what to change.

One thing I want to do is change the event_format structure to
"pevent_event" and the format_field to "pevent_field" just to be more
consistent. There's probably a few other changes as well. But once they
are done, I think we should get this out into a library.


> 
> 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.

We can always add new functions. The old ones will have to be
maintained. Anyway, I'm only looking to what is being used externally
from perf. We can slowly add functionality. The .so releases should
only increment the version if something new is added. I refuse to
follow the gtk crap that they find ways to remove or modify existing
functions every single release.


> 
> 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 ;-)),

Well, I Cc'd some of the maintainers. We can see what they think.

> 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).

Note, I'm only looking at making a library out of what is currently in
tools/lib. We don't need to move stuff out from perf unless you want to.

There's a trace-cmd library I want to have as well, which I would love
to have in the kernel tools/lib directory too. I'd call it
libftrace.so. This would include the ways to parse the ftrace ring
buffer, as well as parsing and creating trace.dat files.

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

Well the event-parse.* code has already been pretty stable. I do want
to do the renames as I mentioned above before making it official. But
once that is done, I would want us to get a libtraceevent.so that
distros can provide.

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

perf, trace-cmd/kernelshark, powertop and ras-daemon

-- Steve

> 
> - 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.