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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ