On Wed, Mar 09, 2016 at 10:47:59AM +0100, Ingo Molnar wrote: > > * Josh Poimboeuf <jpoimboe@xxxxxxxxxx> 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@xxxxxxxxxx> > > --- > > 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 -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
