[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131123131243.GB24148@pd.tnic>
Date: Sat, 23 Nov 2013 14:12:43 +0100
From: Borislav Petkov <bp@...en8.de>
To: Ingo Molnar <mingo@...nel.org>
Cc: Arnaldo Carvalho de Melo <acme@...radead.org>,
LKML <linux-kernel@...r.kernel.org>,
Borislav Petkov <bp@...e.de>, Jiri Olsa <jolsa@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Robert Richter <rric@...nel.org>
Subject: Re: [PATCH] perf: Move fs.* to generic lib/lk/
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.
> 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?
> and as long as the individual .h files are kept_.
This has never stood for debate - headers are kept as is.
> 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?
> 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.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
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/
Powered by blists - more mailing lists