lkml.org 
[lkml]   [2016]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 09/11] tools/objtool: Copy hashtable.h into tools directory
    On Wed, Mar 09, 2016 at 10:47:59AM +0100, Ingo Molnar wrote:
    >
    > * Josh Poimboeuf <jpoimboe@redhat.com> wrote:
    >
    > > Copy hashtable.h from include/linux/tools.h. It's needed by objtool in
    > > the next patch in the series.
    > >
    > > Add some includes that it needs, and remove references to
    > > kernel-specific features like RCU and __read_mostly.
    > >
    > > Also change some if its dependency headers' includes to use quotes
    > > instead of brackets so gcc can find them.
    > >
    > > Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    > > ---
    > > tools/include/asm-generic/bitops/__fls.h | 2 +-
    > > tools/include/asm-generic/bitops/fls.h | 2 +-
    > > tools/include/asm-generic/bitops/fls64.h | 2 +-
    > > tools/include/linux/hashtable.h | 152 +++++++++++++++++++++++++++++++
    > > 4 files changed, 155 insertions(+), 3 deletions(-)
    >
    > So it would be nice to also add a build time warning if the 'upstream' copy of
    > hashtable.h deviates from the tooling file.
    >
    > Just like you are already doing it for other files:
    >
    > objtool/Makefile: diff -I'^#include' arch/x86/insn/insn.c ../../arch/x86/lib/insn.c >/dev/null && \
    >
    > Btw., eventually we might want to factor out such duplication into a single place
    > in tools/lib/ or so, to only have a 'master copy' (upstream kernel source), and
    > the tooling copy.

    Yeah, since we already have at least two instances of this type of
    diffing in the tools tree, it would be good to generalize these diffs in
    a common place with a common kernel build target. I'll add it to my
    TODOs.

    BTW, do you know why the policy is to copy them instead of just
    including the kernel versions?

    If the goal is to make it easier to package the tools separately,
    wouldn't something like the perf MANIFEST file make that possible
    without copying?

    Or if the goal is only to make it possible to compile kernel headers in
    user space, then we may only need to copy or recreate some headers and I
    may have been overzealous with my copying.

    --
    Josh

    \
     
     \ /
      Last update: 2016-03-09 17:41    [W:3.400 / U:0.308 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site