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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 22 Nov 2013 14:50:34 +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 01:27:01PM +0100, Ingo Molnar wrote:
> I don't think those other bits should go into this library. rbtree
> should go into lib/rbtree/, command-line bits into lib/cmdline/, build
> system helpers into lib/build/, etc.
>
> Merging unrelated things into a single library is a user-space disease
> we need not repeat.

Well, rbtree is basically rblist.c and the rbtree*.h headers which
simply wrap the kernel headers.

cmdline is parse-options.c.

IOW, that's splitting it into too granulary pieces with 1-2 compilation
units ber library.

And what if there are interdependencies between the stuff split this
way? That could become very painful and unnecessary.

So having a simple single library which includes generic stuff needed to
interface with the kernel is much simpler and sane, IMHO.

And, since we're keeping it internal, we can do the split the other way
around instead - first do the single generic library and then carve out
a certain subset of functionality if/when it makes sense.

The same approach we can use for the name - first split and work with it
and change stuff when the need for it arises.

> I'd also not expose any of this externally but straight link it into
> the individual utilities - that way it does not matter that it's a
> nice, topical, fine-grained set of functionality.
>
> I don't think we are ready for (nor do we want the overhead of)
> maintaining a library ABI at this stage.
>
> Once things slow down and it's all so robust that we've had at most
> a handful of commits in tools/lib/ in a full year we can think about
> exporting it, maybe ...

Right.
--
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/