Re: [PATCH v1 7/7] tools: add userspace linker table sandbox

[Arnaldo Carvalho de Melo <acme@kernel.org>]

Em Wed, Aug 24, 2016 at 09:20:12AM -0700, Luis R. Rodriguez escreveu:
> On Wed, Aug 24, 2016 at 5:39 AM, Arnaldo Carvalho de Melo
> <acme@kernel.org> 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.

Right
 
> 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

Right, the ones that are direct copies are the ones being checked with
diff, there are others, as you say, that are not copies and are not
being checked at all :-\

Example:

tools/include/linux/rbtree.h

The kernel one has RCU stuff, in it and tools still doesn't have some
userspace RCU implementation that could provide what it expects.

Without collaboration from the kernel people working on
include/linux/rbtree.h, that is what we can do.

> and often ported to libc. So other than the direct copies -- we also
> have another category of headers -- ported headers. Its possible not

yeah

> 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?

I don't see problems with your reasoning, do what is faster for having
your tool in place and we can go on improving the way tools/ gets stuff
from the kernel, how we detect changes that could be interesting to get
and eventually how kernel developers can help in this process.

What we don't want is to burden the kernel developers with things for
tools/.

- Arnaldo