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
>> Both bpftool and libbpf have tools/include/uapi/ in their include path from
>> 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.