Re: [PATCH] perf: Move fs.* to generic lib/lk/

[Ingo Molnar <mingo@kernel.org>]

* Borislav Petkov <bp@alien8.de> wrote:

> On Fri, Nov 22, 2013 at 04:54:25PM +0100, Ingo Molnar wrote:
> > comet:~/tip/tools/perf> ls util/*.h
> > util/annotate.h   util/data.h       util/fs.h           util/parse-events-bison.h  util/probe-event.h   util/sort.h       util/thread.h       util/values.h
> > util/build-id.h   util/debug.h      util/header.h       util/parse-events-flex.h   util/probe-finder.h  util/stat.h       util/thread_map.h   util/vdso.h
> > util/cache.h      util/dso.h        util/help.h         util/parse-events.h        util/pstack.h        util/strbuf.h     util/tool.h         util/xyarray.h
> > util/callchain.h  util/dwarf-aux.h  util/hist.h         util/parse-options.h       util/quote.h         util/strfilter.h  util/top.h
> > util/cgroup.h     util/event.h      util/intlist.h      util/perf_regs.h           util/rblist.h        util/strlist.h    util/trace-event.h
> > util/color.h      util/evlist.h     util/levenshtein.h  util/pmu-bison.h           util/run-command.h   util/svghelper.h  util/types.h
> > util/comm.h       util/evsel.h      util/machine.h      util/pmu-flex.h            util/session.h       util/symbol.h     util/unwind.h
> > util/cpumap.h     util/exec_cmd.h   util/map.h          util/pmu.h                 util/sigchain.h      util/target.h     util/util.h
> > 
> > That is pretty healty granularity IMO.
> > 
> > Do we want a separate directory for each one?
> 
> For each single one of them? This would be insane.

Not necessarily, if the number goes up - obviously then we'd also want 
to add some second directory structure to organize them into broad 
categories or so.

> > I don't see a big problem with doing that, but it could be kept in 
> > tools/lib/util/ or tools/lib/core/ as well,
> 
> That's much better :)
> 
> > _as long as they are not lumped together
> 
> Why not a single .a?

Unnecessarily longer build time.

> > That also means that these bits shouldn't really be librarized in 
> > the classical sense into a single .a and linked into whatever tool 
> > uses it, but should be used individually as singular targets with 
> > clean .h interfaces to utilize them topically.
> 
> Yeah, but why?

If a tool uses just a handful of these (hopefully quickly increasing 
number of) facilities then it should not be burdened by building it 
all.

> > That also means that utilities won't run into any dependency 
> > problems, and the build will be faster as well as it all will be a 
> > single dependency graph within a single make session.
> 
> That's maybe the only half-reason for not lumping them together I've 
> read so far. I say half-reason because the preprocessor already will 
> include only stuff it needs. And if that were a problem, glibc 
> would've been multiple libs too.

The preprocessor does nothing with the .a - eliminating extra stuff 
from the .a is a link time step, and that means the whole .a will be 
built first ... just to throw away bits of it.

( Also, arguably, from a sw design POV glibc should probably have been
  multiple libs, but that's water down the bridge. No need to 
  repeat/clone such mistakes though. )

Thanks,

	Ingo