From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from shards.monkeyblade.net ([184.105.139.130]:39610 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753070AbeCFQAw (ORCPT ); Tue, 6 Mar 2018 11:00:52 -0500 Date: Tue, 06 Mar 2018 11:00:50 -0500 (EST) Message-Id: <20180306.110050.853264455892964392.davem@davemloft.net> To: jbenc@redhat.com Cc: daniel@iogearbox.net, netdev@vger.kernel.org, ast@kernel.org, jakub.kicinski@netronome.com Subject: Re: [PATCH bpf] tools: bpftool: fix compilation with older headers From: David Miller In-Reply-To: <20180306160325.6e16d103@redhat.com> References: <2018378f6cdd5f152ea597071c69b8e0874c769a.1520343947.git.jbenc@redhat.com> <81276ef0-fd65-0db1-5063-efbd4ef80bfa@iogearbox.net> <20180306160325.6e16d103@redhat.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org List-ID: From: Jiri Benc 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.