From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752623AbbLJCx3 (ORCPT ); Wed, 9 Dec 2015 21:53:29 -0500 Received: from LGEAMRELO13.lge.com ([156.147.23.53]:36922 "EHLO lgeamrelo13.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751713AbbLJCx0 (ORCPT ); Wed, 9 Dec 2015 21:53:26 -0500 X-Original-SENDERIP: 156.147.1.126 X-Original-MAILFROM: namhyung@kernel.org X-Original-SENDERIP: 165.244.98.204 X-Original-MAILFROM: namhyung@kernel.org X-Original-SENDERIP: 10.177.227.17 X-Original-MAILFROM: namhyung@kernel.org Date: Thu, 10 Dec 2015 10:40:39 +0900 From: Namhyung Kim To: Josh Poimboeuf CC: Arnaldo Carvalho de Melo , Ingo Molnar , Jiri Olsa , Peter Zijlstra , Ingo Molnar , linux-kernel@vger.kernel.org, Borislav Petkov Subject: Re: [PATCH v2 14/14] perf tools: Move subcommand framework and related utils to libapi Message-ID: <20151210014039.GA13790@sejong> References: <20151208190931.GK11564@kernel.org> <20151208191700.GH14846@treble.redhat.com> <20151208194026.GL11564@kernel.org> <20151208214825.GI14846@treble.redhat.com> <20151208222732.GA15864@kernel.org> <20151208230725.GJ14846@treble.redhat.com> <20151209080343.GA14846@gmail.com> <20151209123315.GA15897@treble.redhat.com> <20151209155808.GO11564@kernel.org> <20151209185915.GA14778@treble.hsd1.ky.comcast.net> MIME-Version: 1.0 In-Reply-To: <20151209185915.GA14778@treble.hsd1.ky.comcast.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-MIMETrack: Itemize by SMTP Server on LGEKRMHUB01/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2015/12/10 11:03:40, Serialize by Router on LGEKRMHUB01/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2015/12/10 11:03:40, Serialize complete at 2015/12/10 11:03:40 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Josh, On Wed, Dec 09, 2015 at 12:59:15PM -0600, Josh Poimboeuf wrote: > On Wed, Dec 09, 2015 at 12:58:08PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Wed, Dec 09, 2015 at 06:33:15AM -0600, Josh Poimboeuf escreveu: > > > On Wed, Dec 09, 2015 at 09:03:43AM +0100, Ingo Molnar wrote: > > > > > > > > * Josh Poimboeuf wrote: > > > > > > > > > > > wouldn't necessarily be a clean split. It would also possibly create more > > > > > > > room for error for the users of libapi, since there would then be three > > > > > > > config interfaces instead of one. > > > > > > > > > > > > Humm, and now that you talk... libapi was supposed to be just sugar coating > > > > > > kernel APIs, perhaps we need to put it somewhere else in tools/lib/ than in > > > > > > tools/lib/api/? > > > > > > > > > > Ah, I didn't realize libapi was a kernel API abstraction library. Shall we put > > > > > it in tools/lib/util instead? > > > > > > > > Yay, naming discussion! ;-) > > > > > > Oh boy! ;-) > > > > > > > So if this is about abstracting out the (Git derived) command-line option parsing > > > > UI and help system, 'util' sounds a bit too generic. > > > > > > > > We could call it something like 'lib/cmdline', 'lib/options'? > > > > > > > > The (old) argument against making too finegrained user-space libraries was that > > > > shared libraries do have extra runtime costs - this thinking resulted in catch-all > > > > super-libraries like libgtk: > > > > > > > > size /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > > > > text data bss dec hex filename > > > > 7199789 57712 15128 7272629 6ef8b5 /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 > > > > > > > > But in tools/ we typically link the libraries statically so there's no shared > > > > library cost to worry about. (Build time linking is a good idea anyway, should we > > > > ever want to make use of link-time optimizations. It also eliminates version skew > > > > and library compatibility breakage.) > > > > > > > > The other reason for the emergence of super-libraries was the high setup cost of > > > > new libraries: it's a lot easier to add yet another unrelated API to libgtk than > > > > to start up a whole new project and a new library. But this setup cost is very low > > > > in tools/ - one of the advantage of shared repositories. > > > > > > > > So I think in tools/lib/ we can continue to do a clean topical separation of > > > > libraries, super-libraries are not needed. > > > > > > I definitely agree that for the reasons you outlined, something like > > > 'lib/cmdline' would be a good idea. Except... there's a wrinkle, of > > > course. > > > > > > The library also includes non-cmdline-related dependencies. And these > > > dependencies are directly used by perf as well. So if we name it > > > 'cmdline', perf would have includes like: > > > > > > #include > > > #include > > > #include > > > #include > > > ...etc... > > > > > > So it would be using several functions from the 'cmdline' library which > > > are unrelated to 'cmdline'. > > > > > > For that reason I would vote to name it 'lib/util'. But I don't really > > > care, I'd be ok with 'lib/marshmallow' if that's what you guys wanted > > > :-) > > > > Right, now you see why this wasn't librarised before, huh? Untangling > > bits in a way that this gets sane takes a bit of time. > > > > I'm going thru your patchkit to erode it a bit, taking uncontroversial > > patches. > > > > I also would just do one thing first, i.e. just move the cmdline parts > > to lib/cmdline/, then we would look at the rest. I.e. reduce the problem > > first. > > > > Yeah, I haven't looked deeply how difficult that would be :-\ > > Ok. I've taken a deeper look at how we could just have a 'cmdline' > library without the extra unrelated utils. > > (BTW, I actually think a name like 'subcmd' would be a better fit than > 'cmdline'. Because it deals not only with the cmdline, but more > specifically with subcommands, as well as the exec'ing of external > subcommands and other subprograms. And any program that wants to have a > "perf"- or "git"-like "subcommand" interface would use it, thus 'subcmd' > is a more natural fit.) 'subcmd' looks good to me too. > > I looked at the files which are unrelated to subcommands and which are > used by both the subcmd code and perf: > > - abspath.c: needed by exec_cmd.c for the make_nonrelative_path() > function, but it's a small function which can just be duplicated by > copying it into exec_cmd.c. > > - ctype.c: used by parse-options.c for tolower(), but it's not strictly > necessary; instead the glibc version of tolower() can be used. I vaguely recall that it's related to a locale issue. But I don't know what was the problem exactly. > > - pager.c: this isn't directly 'cmdline' related, but does fit the theme > of 'subcmd', since it pipes a child process to 'less'. So it could > reasonably live in the library. > > - strbuf.c: used sparingly by parse-options.c, exec_cmd.c, and help.c. > I think all the uses can be replaced rather easily with calls to > sprintf() and similar glibc string functions. > > (Another option would be to duplicate the ~150 lines of strbuf.c > inside the library. That would require renaming all the functions and > structs in order to avoid duplicate symbol errors when linking with > perf.) > > - term.c: used by help.c for the get_term_dimensions() function, which > is a small function which can be duplicated in help.c. > > - usage.c: used in several places for die() and error(), but these are > trivial functions which can be duplicated. Not sure it's ok to call die() or similar in a library. The error should be reported to the caller rather than exiting inside unless explicitly requested like in usage_with_options() IMHO. Thanks, Namhyung > > - wrapper.c: used in a few places for ALLOC_GROW() and xrealloc(), but > ALLOC_GROW() can be duplicated locally and xrealloc() can be replaced > by the use of realloc(). > > So in summary, with a small amount of code duplication, and a little > rewrite of the strbuf usage, I think I can extract a libsubcmd rather > cleanly. > > How does that sound? > > -- > Josh