Date:	Wed, 13 Jul 2016 17:01:48 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Adrian Hunter <adrian.hunter@...el.com>,
	David Ahern <dsahern@...il.com>, Jiri Olsa <jolsa@...nel.org>,
	Namhyung Kim <namhyung@...nel.org>,
	Wang Nan <wangnan0@...wei.com>,
	Clark Williams <williams@...hat.com>,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Alexandra Yates <alexandra.yates@...ux.intel.com>,
	Nivedita Swaminathan <nivedita.swaminathan@...el.com>
Subject: Re: [PATCH 29/66] tools lib traceevent: Use str_error_r()

Em Wed, Jul 13, 2016 at 03:17:00PM -0400, Steven Rostedt escreveu:
> On Wed, 13 Jul 2016 10:51:25 -0300
> Arnaldo Carvalho de Melo <acme@...nel.org> 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@...nel.org> 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

Hey, that is what I call enthusiasm, expecting the patches!

> from external sources to begin with. I've been working hard to try to

What code "that come from external sources" are you talking about?

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

Ah, you're talking about just tools/lib/traceevent/ ?
 
> 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.

Hey, if it is only rom tools/lib/traceevent, I have no worries, you're
the one proposing turning it into a committed to ABI and you're the main
author, also willing to do the work of turning it into a .so, fair enough.

As time goes by and the changes take place that requires we to write
tools/build/feature/ entries to cope with changes in its ABI, we'll just
do it, it will be just another external library we need and can't do
changes in tandem with tools/perf/, we'll have to suport old versions,
do feature checks to see if the one present in a particular
distro/release has some new feature, etc, etc.
 
> 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.

I was confused, I was thinking you were talking about code other than
tools/lib/traceevent/.

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

> > Which ones?
 
> perf, trace-cmd/kernelshark, powertop and ras-daemon

Cool, so this is all just about tools/lib/traceevent/ after all, sure,
go ahead, you're the "external source" after all :-)

- Arnaldo

Powered by blists - more mailing lists