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@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
