Em Thu, Nov 28, 2013 at 01:16:57PM +0100, Borislav Petkov escreveu:
> On Wed, Nov 27, 2013 at 04:39:44PM +0100, Borislav Petkov wrote:
> > Ok, splitting them into topics actually makes sense.
> >
> > > But stuffing them into types.a, formats.a, kernel.a, not so much.
> >
> > Huh, why not? We
Em Thu, Nov 28, 2013 at 01:16:57PM +0100, Borislav Petkov escreveu:
On Wed, Nov 27, 2013 at 04:39:44PM +0100, Borislav Petkov wrote:
Ok, splitting them into topics actually makes sense.
But stuffing them into types.a, formats.a, kernel.a, not so much.
Huh, why not? We take the
On Wed, Nov 27, 2013 at 04:39:44PM +0100, Borislav Petkov wrote:
> Ok, splitting them into topics actually makes sense.
>
> > But stuffing them into types.a, formats.a, kernel.a, not so much.
>
> Huh, why not? We take the corresponding .c files and create a single .a
> archive per topic from
On Wed, Nov 27, 2013 at 04:39:44PM +0100, Borislav Petkov wrote:
Ok, splitting them into topics actually makes sense.
But stuffing them into types.a, formats.a, kernel.a, not so much.
Huh, why not? We take the corresponding .c files and create a single .a
archive per topic from them. This
On Tue, Nov 26, 2013 at 07:03:33PM +0100, Ingo Molnar wrote:
> Not necessarily, if the number goes up - obviously then we'd also want
> to add some second directory structure to organize them into broad
> categories or so.
Right, topic libraries. That is starting to make more sense. :)
>
On Tue, Nov 26, 2013 at 07:17:45PM +0100, Ingo Molnar wrote:
> It's a single line added to the Makefile, the moment a .h is used for
> the first time. That's not any appreciable overhead.
Hmm, not quite. It is a bit more jumping through hoops - look at the
variables LK_DIR, LK_PATH and LIBLK for
On Tue, Nov 26, 2013 at 07:17:45PM +0100, Ingo Molnar wrote:
It's a single line added to the Makefile, the moment a .h is used for
the first time. That's not any appreciable overhead.
Hmm, not quite. It is a bit more jumping through hoops - look at the
variables LK_DIR, LK_PATH and LIBLK for
On Tue, Nov 26, 2013 at 07:03:33PM +0100, Ingo Molnar wrote:
Not necessarily, if the number goes up - obviously then we'd also want
to add some second directory structure to organize them into broad
categories or so.
Right, topic libraries. That is starting to make more sense. :)
* Borislav Petkov wrote:
> On Fri, Nov 22, 2013 at 04:39:11PM +0100, Ingo Molnar wrote:
>
> > I see no problem with that - it's basically like util/*.c is, just
> > between tools.
>
> But why? Why it is a good thing to have to pay attention to linking
> to 10 minilibs when you're using 10
* Borislav Petkov wrote:
> 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
* Borislav Petkov b...@alien8.de wrote:
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
* Borislav Petkov b...@alien8.de wrote:
On Fri, Nov 22, 2013 at 04:39:11PM +0100, Ingo Molnar wrote:
I see no problem with that - it's basically like util/*.c is, just
between tools.
But why? Why it is a good thing to have to pay attention to linking
to 10 minilibs when you're using
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
On Fri, Nov 22, 2013 at 04:39:11PM +0100, Ingo Molnar wrote:
> I see no problem with that - it's basically like util/*.c is, just
> between tools.
But why? Why it is a good thing to have to pay attention to linking to
10 minilibs when you're using 10 utilities for your tool instead of a
small
On Fri, Nov 22, 2013 at 04:39:11PM +0100, Ingo Molnar wrote:
I see no problem with that - it's basically like util/*.c is, just
between tools.
But why? Why it is a good thing to have to pay attention to linking to
10 minilibs when you're using 10 utilities for your tool instead of a
small
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
* Ingo Molnar 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
* Arnaldo Carvalho de Melo wrote:
> Lets experiment at having things at the right granularity, even if
> it involves many, directly linked, like libperf.a, libraries, one at
> a time, starting with fskapi (or whatever name ends up being
> preferred for this initial one).
That's fine with me
* Borislav Petkov wrote:
> 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
On 11/22/13, 8:00 AM, Arnaldo Carvalho de Melo wrote:
Lets do one at a time, so far we agreed that the ones that involves
parsing procfs/sysfs etc should go in tools/lib/(fs)?kapi, so lets do
that one.
libsysfs & libsysfs-devel?
--
To unsubscribe from this list: send the line "unsubscribe
Em Fri, Nov 22, 2013 at 02:50:34PM +0100, Borislav Petkov escreveu:
> 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
Em Fri, Nov 22, 2013 at 01:27:01PM +0100, Ingo Molnar escreveu:
> * Arnaldo Carvalho de Melo wrote:
> > Em Thu, Nov 21, 2013 at 04:28:04PM +0100, Borislav Petkov escreveu:
> > > On Thu, Nov 21, 2013 at 12:05:24PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > Naming is a bit hard, to keep it
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
* Arnaldo Carvalho de Melo wrote:
> Em Thu, Nov 21, 2013 at 04:28:04PM +0100, Borislav Petkov escreveu:
> > On Thu, Nov 21, 2013 at 12:05:24PM -0300, Arnaldo Carvalho de Melo wrote:
> > > "To offers various helper methods to interface with the Linux kernel:
> > > debugfs, procfs, sysfs
* Arnaldo Carvalho de Melo a...@infradead.org wrote:
Em Thu, Nov 21, 2013 at 04:28:04PM +0100, Borislav Petkov escreveu:
On Thu, Nov 21, 2013 at 12:05:24PM -0300, Arnaldo Carvalho de Melo wrote:
To offers various helper methods to interface with the Linux kernel:
debugfs, procfs, sysfs
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
Em Fri, Nov 22, 2013 at 01:27:01PM +0100, Ingo Molnar escreveu:
* Arnaldo Carvalho de Melo a...@infradead.org wrote:
Em Thu, Nov 21, 2013 at 04:28:04PM +0100, Borislav Petkov escreveu:
On Thu, Nov 21, 2013 at 12:05:24PM -0300, Arnaldo Carvalho de Melo wrote:
Naming is a bit hard, to keep
Em Fri, Nov 22, 2013 at 02:50:34PM +0100, Borislav Petkov escreveu:
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
On 11/22/13, 8:00 AM, Arnaldo Carvalho de Melo wrote:
Lets do one at a time, so far we agreed that the ones that involves
parsing procfs/sysfs etc should go in tools/lib/(fs)?kapi, so lets do
that one.
libsysfs libsysfs-devel?
--
To unsubscribe from this list: send the line unsubscribe
* Borislav Petkov b...@alien8.de wrote:
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
* Arnaldo Carvalho de Melo a...@ghostprotocols.net wrote:
Lets experiment at having things at the right granularity, even if
it involves many, directly linked, like libperf.a, libraries, one at
a time, starting with fskapi (or whatever name ends up being
preferred for this initial one).
* Ingo Molnar mi...@kernel.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
From: Borislav Petkov
Move to generic library and kill magic.h as it is needed only in fs.h.
Signed-off-by: Borislav Petkov
---
Ok, let's try the first one, see how it goes.
tools/lib/lk/Makefile | 2 ++
tools/{perf/util => lib/lk}/fs.c
From: Borislav Petkov b...@suse.de
Move to generic library and kill magic.h as it is needed only in fs.h.
Signed-off-by: Borislav Petkov b...@suse.de
---
Ok, let's try the first one, see how it goes.
tools/lib/lk/Makefile | 2 ++
tools/{perf/util =
34 matches
Mail list logo
