lkml.org 
[lkml]   [2015]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 14/14] perf tools: Move subcommand framework and related utils to libapi
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@redhat.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 :-\

- Arnaldo


\
 
 \ /
  Last update: 2015-12-09 17:21    [W:0.085 / U:0.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site