On Wed, Aug 24, 2016 at 5:39 AM, Arnaldo Carvalho de Melo
[off-list ref] wrote:

Changes detected by the tools build system:

      $ make -C tools/perf O=/tmp/build/perf install-bin
      make: Entering directory '/home/acme/git/linux/tools/perf'
        BUILD:   Doing 'make -j4' parallel build
--->  Warning: tools/include/uapi/linux/bpf.h differs from kernel <-------
        INSTALL  GTK UI
        CC       /tmp/build/perf/bench/mem-memcpy-x86-64-asm.o
      <SNIP>
      $

I borrowed the same strategy from perf tools and generalized this
through helpers a bit as Makefile helpers in the linker-tables
sandbox:

HEADERS = \
          ../../include/asm-generic/section-core.h \
          ../../include/asm-generic/ranges.h \
          ../../include/asm-generic/tables.h \
          ../../include/linux/sections.h \
          ../../include/linux/ranges.h \
          ../../include/linux/tables.h

__check_headers: $(HEADERS)
        @$(foreach h, $(HEADERS), \
                (test -f $(h) && ( \
                        (diff -B $(subst ../,../,$(h)) $(h) >/dev/null) \
                        || echo "Warning: $(subst ../../,tools/,$(h))
differs from kernel" >&2 ) || true);)


Instead of doing the check / complaint at install it complains at
build time. Its up to the tools to decide when they want this check,
but perhaps later a generic check can be set up. My thought was later
to move some of this as helpers in a generic tools Makefile to more
easily enable other tools/ to do similar checks more easily. I suspect
we may later want to keep a tighter tab on what tools need what
headers and instead have a generic place to keep tabs on this, but we
can do that slowly later after generalizing a checker.

In doing the linker table sandbox one of the needs I found in needing
separate headers was that often you don't want the same copy as the
kernel provides, as you want to port things over to work in userspace
and often ported to libc. So other than the direct copies -- we also
have another category of headers -- ported headers. Its possible not
all tools may end up wanting the same port, this can be addressed
through two means. One is having a generic port which should suffice
for most tools that need libc, and for those that don't want the
generic port they can just carry their own port in their own tree. The
linker tables tools sandbox enables this by allowing first headers to
be search in its own directory, that way it can override what is
provided as generic in tools. However it may still be useful later to
have two separate directories to be able to easily distinguish between
"copies" and "ports". But this can be done later.

Thoughts?

  Luis