Em Tue, Aug 10, 2010 at 04:32:41PM +0200, Sam Ravnborg escreveu:
quoted text
> On Tue, Aug 10, 2010 at 10:46:00AM -0300, Arnaldo Carvalho de Melo wrote:
> > Idea is to try to have the perf tools, since they are hosted in the
> > kernel and developed mostly by people with kernel background, to use
> > code and practices used in the kernel proper.

quoted text
> > It started just keeping private copies, I guess it should get back to
> > that since the reaction to this kind of same source repo code sharing
> > was, well, not good :-)

quoted text
> > Alternatives?
 
quoted text
> I have not analyzed deeper in what parts perf uses so the following
> may not fly at all.

quoted text
> One solution could be to let perf rely on a set of exported userspace
> headers from the kernel.

Yeah, finding things that could be shared was part of this exercise, as some
people mentioned that lots of userspace programs out there already have
list.h copies.

Petrifying list.h (and other headers) for the sake of out of the kernel use
probably won't get many supporters, for things that ship and are developed in
the same source repo tho, perhaps can be made possible.

quoted text
> And on top of this copy a small set of kernel internal headers for use
> by perf only.  The copying will be a good way to document what is
> actually used of the kernel internal stuff.

Yeah, that to me is the easier, non controversial path to take, like done with
hweight.c et all, I'll do that.
 
quoted text
> But I also realize that just copying over list.h does not suffice. It
> pulls in lots of other stuff.  So this is most likely hard to do.
> 
> I guess first step is to identify what is really used beside the
> exported stuff and start to conclude from there.

This is what I did for hweight.c in:

[acme@doppio linux-2.6-tip]$ git log tools/perf/util/hweight.c 
commit fb72014d98afd51e85aab9c061344ef32d615606
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Fri Apr 30 19:31:12 2010 -0300

    perf tools: Don't use code surrounded by __KERNEL__
    
    We need to refactor code to be explicitely shared by the kernel and at
    least the tools/ userspace programs, so, till we do that, copy the bare
    minimum bitmap/bitops code needed by tools/perf.
    
    Reported-by: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Frédéric Weisbecker <fweisbec@gmail.com>
    Cc: Mike Galbraith <efault@gmx.de>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    LKML-Reference: <new-submission>
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
[acme@doppio linux-2.6-tip]$

I will continue that exercise and leave explicitely sharing stuff with
the kernel for later, if ever.

Then we will just have to track changes to the initially shared stuff so
that we don't miss fixes like described in the cset where some of this
sharing was started:

commit 43cbcd8acb4c992cbd22d1ec8a08c0591be5d719
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Wed Jul 1 12:28:37 2009 -0300

    perf_counter tools: Share rbtree.with the kernel
    
    The tools/perf/util/rbtree.c copy already drifted by three
    csets:
    
     4b324126e0c6c3a5080ca3ec0981e8766ed6f1ee
     4c60117811171d867d4f27f17ea07d7419d45dae
     16c047add3ceaf0ab882e3e094d1ec904d02312d

    So remove the copy and use the lib/rbtree.c directly, sharing
    the source code while still generating a separate object file,
    since tools/perf uses a far more agressive -O6 switch.
    
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Mike Galbraith <efault@gmx.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    LKML-Reference: <20090701152837.GG15682@ghostprotocols.net>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

- Arnaldo
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/