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

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20131122155425.GA15836@gmail.com>
Date:	Fri, 22 Nov 2013 16:54:25 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Borislav Petkov <bp@...en8.de>
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/


* Ingo Molnar <mingo@...nel.org> wrote:

> > cmdline is parse-options.c.
> > 
> > IOW, that's splitting it into too granulary pieces with 1-2 
> > compilation units ber library.
> 
> I see no problem with that - it's basically like util/*.c is, just 
> between tools.

I.e.:

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? 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, _as long as they are not lumped together and 
as long as the individual .h files are kept_.

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.

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.

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/