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.

Reply via email to