From: Borislav Petkov <bp@alien8.de>
To: Ingo Molnar <mingo@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@infradead.org>,
LKML <linux-kernel@vger.kernel.org>, Borislav Petkov <bp@suse.de>,
Jiri Olsa <jolsa@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Robert Richter <rric@kernel.org>
Subject: Re: [PATCH] perf: Move fs.* to generic lib/lk/
Date: Fri, 22 Nov 2013 14:50:34 +0100 [thread overview]
Message-ID: <20131122135034.GA20146@nazgul.tnic> (raw)
In-Reply-To: <20131122122701.GA1480@gmail.com>
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.
next prev parent reply other threads:[~2013-11-22 13:50 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-20 21:56 Borislav Petkov
2013-11-21 7:34 ` Ingo Molnar
2013-11-21 10:07 ` Borislav Petkov
2013-11-21 11:17 ` Ingo Molnar
2013-11-21 11:30 ` Borislav Petkov
2013-11-21 11:42 ` Ingo Molnar
2013-11-21 12:06 ` Borislav Petkov
2013-11-21 12:39 ` Steven Rostedt
2013-11-21 13:49 ` Borislav Petkov
2013-11-21 13:56 ` Steven Rostedt
2013-11-21 14:18 ` Borislav Petkov
2013-11-21 15:12 ` Arnaldo Carvalho de Melo
2013-11-21 15:05 ` Arnaldo Carvalho de Melo
2013-11-21 15:28 ` Borislav Petkov
2013-11-21 17:37 ` Arnaldo Carvalho de Melo
2013-11-21 19:00 ` Borislav Petkov
2013-11-22 12:27 ` Ingo Molnar
2013-11-22 13:50 ` Borislav Petkov [this message]
2013-11-22 15:00 ` Arnaldo Carvalho de Melo
2013-11-22 15:20 ` David Ahern
2013-11-22 15:39 ` Ingo Molnar
2013-11-22 15:54 ` Ingo Molnar
2013-11-23 13:12 ` Borislav Petkov
2013-11-26 18:03 ` Ingo Molnar
2013-11-27 15:42 ` Borislav Petkov
2013-11-23 13:04 ` Borislav Petkov
2013-11-26 18:17 ` Ingo Molnar
2013-11-27 15:39 ` Borislav Petkov
2013-11-28 12:16 ` Borislav Petkov
2013-12-02 20:30 ` Arnaldo Carvalho de Melo
2013-11-22 14:57 ` Arnaldo Carvalho de Melo
2013-11-22 15:43 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131122135034.GA20146@nazgul.tnic \
--to=bp@alien8.de \
--cc=acme@infradead.org \
--cc=bp@suse.de \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rric@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®