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

* 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! ;-)

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.

Thanks,

Ingo


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