From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753931AbbLIMdT (ORCPT ); Wed, 9 Dec 2015 07:33:19 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55910 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751370AbbLIMdS (ORCPT ); Wed, 9 Dec 2015 07:33:18 -0500 Date: Wed, 9 Dec 2015 06:33:15 -0600 From: Josh Poimboeuf To: Ingo Molnar Cc: Arnaldo Carvalho de Melo , Jiri Olsa , Peter Zijlstra , Ingo Molnar , linux-kernel@vger.kernel.org, Namhyung Kim , Borislav Petkov Subject: Re: [PATCH v2 14/14] perf tools: Move subcommand framework and related utils to libapi Message-ID: <20151209123315.GA15897@treble.redhat.com> References: <0374ac2777cfb277f395de8423d670265400eb1b.1449548395.git.jpoimboe@redhat.com> <20151208181625.GB18433@krava.brq.redhat.com> <20151208184953.GG14846@treble.redhat.com> <20151208190931.GK11564@kernel.org> <20151208191700.GH14846@treble.redhat.com> <20151208194026.GL11564@kernel.org> <20151208214825.GI14846@treble.redhat.com> <20151208222732.GA15864@kernel.org> <20151208230725.GJ14846@treble.redhat.com> <20151209080343.GA14846@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20151209080343.GA14846@gmail.com> User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 09, 2015 at 09:03:43AM +0100, Ingo Molnar wrote: > > * Josh Poimboeuf 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 #include #include #include ...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 :-) Thoughts? -- Josh