Messages in this thread | | | Date | Wed, 9 Dec 2015 09:03:43 +0100 | From | Ingo Molnar <> | Subject | Re: [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
| |