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 <jpoim...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
