From: Jiri Benc <jb...@redhat.com> Date: Tue, 6 Mar 2018 16:03:25 +0100
> On Tue, 6 Mar 2018 15:39:07 +0100, Daniel Borkmann wrote: >> Thanks for the fix, Jiri! The standard approach to resolve such header >> dependencies under >> tools/ would be to add a copy of magic.h uapi header into >> tools/include/uapi/linux/magic.h. >> >> Both bpftool and libbpf have tools/include/uapi/ in their include path from >> their >> Makefile, so they would pull this in automatically and it would also allow >> to get rid >> of the extra ifdef in libbpf then. Could you look into that? > > That's what I tried at first. But honestly, this is a shortcut to hell. > Eventually, we'd end up with most of uapi headers duplicated under > tools/include/uapi and hopelessly out of sync. > > The right approach would be to export uapi headers from the currently > built kernel somewhere (a temporary directory, perhaps) and use that to > build the tools. We should not have duplicated and out of sync headers > in the kernel tree. Just look at the git log for tools/include/uapi to > see what I mean by "out of sync". I understand your frustration. I'm really puzzled why doing "make headers_install" and then building these tools does not pick those in-kernel headers up. That's what really should happen. The kernel tree internally should be self-consistent. It's one thing for an external tool like iproute2 to duplicate stuff like this, but user programs inside the kernel have no excuse for requiring things like that just to build.
