Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753786AbdLURee (ORCPT ); Thu, 21 Dec 2017 12:34:34 -0500 Received: from mail-qk0-f193.google.com ([209.85.220.193]:37124 "EHLO mail-qk0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752629AbdLURe0 (ORCPT ); Thu, 21 Dec 2017 12:34:26 -0500 X-Google-Smtp-Source: ACJfBos7CY+sBnAF7j4FalhJ5geOnpPRsFYXSasb+job47djIlohQXqJsS80A1J1Yz0DEPh4o+sgWQ== Date: Thu, 21 Dec 2017 09:34:21 -0800 From: Jakub Kicinski To: Roman Gushchin Cc: , , , , Alexei Starovoitov , Daniel Borkmann , Arnaldo Carvalho de Melo Subject: Re: [RFC PATCH net-next] tools/bpftool: use version from the kernel source tree Message-ID: <20171221093421.4199338c@cakuba.netronome.com> In-Reply-To: <20171221120736.GA7054@castle.DHCP.thefacebook.com> References: <20171220201943.24440-1-guro@fb.com> <20171220122921.62e10f33@cakuba.netronome.com> <20171220205332.GA28352@castle> <20171220135218.1ed54acb@cakuba.netronome.com> <20171221120736.GA7054@castle.DHCP.thefacebook.com> Organization: Netronome Systems, Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2922 Lines: 49 On Thu, 21 Dec 2017 12:07:42 +0000, Roman Gushchin wrote: > On Wed, Dec 20, 2017 at 01:52:18PM -0800, Jakub Kicinski wrote: > > On Wed, 20 Dec 2017 20:53:41 +0000, Roman Gushchin wrote: > > > On Wed, Dec 20, 2017 at 12:29:21PM -0800, Jakub Kicinski wrote: > > > Hm, why it's better? It's not only about the kernel version, > > > IMO it's generally better to use includes from the source tree, > > > rather then system-wide installed kernel headers. > > > > Right I agree the kernel headers are preferred. I'm not entirely sure > > why we don't use them, if it was OK to assume usr/ is there we wouldn't > > need the tools/include/uapi/ contraption. Maybe Arnaldo could explain? > > > > > I've got about out-of-source builds, but do we support it in general? > > > How can I build bpftool outside of the kernel tree? > > > I've tried a bit, but failed. > > > > This is what I do: > > > > make -C tools/bpf/bpftool/ W=1 O=/tmp/builds/bpftool > > This works perfectly with my patch: > > $ make -C ~/linux/tools/bpf/ W=1 O=/home/guro/build/ --trace > <...> > echo ' CC '/home/guro/build/main.o;gcc -O2 -W -Wall -Wextra -Wno-unused-parameter -Wshadow -D__EXPORTED_HEADERS__ -I/home/guro/linux/tools/include/uapi -I/home/guro/linux/tools/include -I/home/guro/linux/tools/lib/bpf -I/home/guro/linux/kernel/bpf/ -I/home/guro/linux/usr/include -DNEW_DISSASSEMBLER_SIGNATURE -c -MMD -o /home/guro/build/main.o main.c > <...> > echo ' LINK '/home/guro/build/bpftool;gcc -O2 -W -Wall -Wextra -Wno-unused-parameter -Wshadow -D__EXPORTED_HEADERS__ -I/home/guro/linux/tools/include/uapi -I/home/guro/linux/tools/include -I/home/guro/linux/tools/lib/bpf -I/home/guro/linux/kernel/bpf/ -I/home/guro/linux/usr/include -DNEW_DISSASSEMBLER_SIGNATURE -o /home/guro/build/bpftool /home/guro/build/common.o /home/guro/build/cgroup.o /home/guro/build/main.o /home/guro/build/json_writer.o /home/guro/build/prog.o /home/guro/build/map.o /home/guro/build/jit_disasm.o /home/guro/build/disasm.o /home/guro/build/libbpf.a -lelf -lbfd -lopcodes /home/guro/build/libbpf.a > LINK /home/guro/build/bpftool > make[1]: Leaving directory '/home/guro/linux/tools/bpf/bpftool' > make: Leaving directory '/home/guro/linux/tools/bpf' > > $ ./build/bpftool version > ./build/bpftool v4.15.0 Argh, sorry for the confusion you need to build the kernel out-of-source as well. In my case I build the kernel and bpftool out of source, and then the usr/ doesn't actually contain the auto-generated headers: $ ls ~/devel/linux/usr/ gen_init_cpio.c initramfs_data.S Kconfig Makefile Only build directory does: $ ls /tmp/builds/usr/ built-in.o gen_init_cpio include initramfs_data.cpio initramfs_data.o modules.builtin modules.order Let me reiterate, the user space headers we need should all be already included in -I$(srctree)/tools/include/uapi, and make kernelversion is nice because it also adds the -rc tags.