Message-ID: <20151210145445.GC29872@treble.redhat.com>
Date:	Thu, 10 Dec 2015 08:54:45 -0600
From:	Josh Poimboeuf <jpoimboe@...hat.com>
To:	Namhyung Kim <namhyung@...nel.org>
Cc:	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Ingo Molnar <mingo@...nel.org>, Jiri Olsa <jolsa@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH v2 14/14] perf tools: Move subcommand framework and
 related utils to libapi

On Thu, Dec 10, 2015 at 10:40:39AM +0900, Namhyung Kim wrote:
> 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 <jpoimboe@...hat.com> 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 <cmdline/pager.h>
> > > > #include <cmdline/strbuf.h>
> > > > #include <cmdline/term.h>
> > > > #include <cmdline/wrapper.h>
> > > > ...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.

Ok, thanks!

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

Ah, I think you're right.  From the ctype man page:

  If c is a uppercase letter, tolower() returns its lowercase
  equivalent, if a lowercase representation exists in the current
  locale.

In this case, tolower() is just used for sorting the printed option list
by the lowercase version of their short option.  IMO it's fine to use
the glibc locale-specific conversion here.

> > - 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, good point.  I'll try to remove all exits from the library
(except for the explicit requests).

-- 
Josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists