linux-kernel - Re: [PATCH v2 14/14] perf tools: Move subcommand framework and related utils to libapi

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 9 Dec 2015 09:03:43 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Josh Poimboeuf <jpoimboe@...hat.com>
Cc:	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Jiri Olsa <jolsa@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	Namhyung Kim <namhyung@...nel.org>,
	Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH v2 14/14] perf tools: Move subcommand framework and
 related utils to libapi

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

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