From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751448AbcGMUCT (ORCPT ); Wed, 13 Jul 2016 16:02:19 -0400 Received: from mail.kernel.org ([198.145.29.136]:33564 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751009AbcGMUCH (ORCPT ); Wed, 13 Jul 2016 16:02:07 -0400 Date: Wed, 13 Jul 2016 17:01:48 -0300 From: Arnaldo Carvalho de Melo To: Steven Rostedt Cc: Ingo Molnar , linux-kernel@vger.kernel.org, Arnaldo Carvalho de Melo , Adrian Hunter , David Ahern , Jiri Olsa , Namhyung Kim , Wang Nan , Clark Williams , Mauro Carvalho Chehab , Arjan van de Ven , Alexandra Yates , Nivedita Swaminathan Subject: Re: [PATCH 29/66] tools lib traceevent: Use str_error_r() Message-ID: <20160713200148.GA6961@kernel.org> References: <1468363241-14555-1-git-send-email-acme@kernel.org> <1468363241-14555-30-git-send-email-acme@kernel.org> <20160712191108.63d23fae@gandalf.local.home> <20160712231424.GA26691@kernel.org> <20160712192519.601b1fae@gandalf.local.home> <20160712233218.GB26691@kernel.org> <20160713083001.1dfa2b0e@gandalf.local.home> <20160713135125.GA27879@kernel.org> <20160713151700.3cc8f65e@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160713151700.3cc8f65e@gandalf.local.home> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 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