Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp3132989ybl; Mon, 20 Jan 2020 16:44:53 -0800 (PST) X-Google-Smtp-Source: APXvYqxAHHRshfFEhPMjQ+bWl2hGf2EbPvJV65uKuagt426TjOJeGj/NQM4ll8Z92VmXcfiW32IO X-Received: by 2002:a9d:10e:: with SMTP id 14mr1623663otu.59.1579567493788; Mon, 20 Jan 2020 16:44:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579567493; cv=none; d=google.com; s=arc-20160816; b=br7GSBjxlPL4esAgUENl/ccXJ9YTJRSSwsMdHG62NRaXhBfyYe3HP6sV8J6BIKU8N3 iLl59ke5jSB6v4IjzmQD2UZf91J3/bwE1cYBKrP4NbAEugW8vGKb6RFSfph+3d3SJJ0k NSzMywScyfu6/aJojOf8PluXdofu+EoFGwzRaJ8jqo13v9yXJk6NgqbwD1Qznmb9DeT1 hOG8rvD3NZI1okIvtHke/TlNhP19A7V8B9xxWRoNgBDmWW89Mwu4fokULQA8mRtvqNZN mkEnXSG8JtwX9XWFal+dHYgqhkRIuwTIVQjarOnOtgMmlrMrMXRIgkzZg6bzz/oiJofv 30BQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=MkxVpkj1L/adI2wMhsZ5ahtdW6aCQqf2r6PjbRYhDUc=; b=wLvjrQUHMqaG3vWvv3ifiuVD8sXdHc9Z4rH7uG9BmvKCXYgu+vhX5kPDUJQ8Kk0UUL 2LNTKoSRIvGRKtVCnao1VCxUoszg9zxdN+lblz5nBzk6ek0F47M1hJ1SIUVnoEc/JDRz VdCq6fLXJmnh0XQlsZXDnFxQCgnimeZPk4NTDfNgP3zTmlxGbS7grUKk8k/dQCFbn8R9 iSUWHsgF5MbYUIv5NzDLHO+FjvudISav12B+PTwv0+lLvy1mMtPRdhmZuYvn09kBlUdF 1lzRJuJnlAHl+jQofk+JWaYgdAbSMF+e0pItAumkcLOZo98BEchK3ua3hQvQ5UkhJcJW 8oyg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dZ1awvxM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c79si19281205oig.208.2020.01.20.16.44.41; Mon, 20 Jan 2020 16:44:53 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dZ1awvxM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728827AbgAUAnt (ORCPT + 99 others); Mon, 20 Jan 2020 19:43:49 -0500 Received: from mail-lj1-f195.google.com ([209.85.208.195]:41059 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727009AbgAUAnt (ORCPT ); Mon, 20 Jan 2020 19:43:49 -0500 Received: by mail-lj1-f195.google.com with SMTP id h23so903711ljc.8; Mon, 20 Jan 2020 16:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MkxVpkj1L/adI2wMhsZ5ahtdW6aCQqf2r6PjbRYhDUc=; b=dZ1awvxMcrnEKYwMzrqTRi2pwnOM1B5AEpM5WeGi/zFyuzcBUSETgpwjirtQ358y6Z EFNOO3SLwuri1vDF5uO6cCRQDwLLkI0K7dUzsY7rF2MxA0AS+w+l1Rk2UJj9u9y+S9jg ORg7FsklegjviEhG0dwRt/0Z4CtiY7xb0aaO6pUrA8lu66Kx8ca2A+a2gtpYgNaFoMA5 jCIpX/nQPF/I7vKX7ZDEGZHU3PW95G0oAsZY18VzoI6dVY2g8tazNhztC3HUUZr9DCY6 cyDc0LKwr9gFXVBpSzWwmih7u3zc9QksSbwtx/fvxag2DlCU7xqS+ypGRbKjm0KqL6ef paVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MkxVpkj1L/adI2wMhsZ5ahtdW6aCQqf2r6PjbRYhDUc=; b=l0Z6V6oXpvQc5CFbpuk2z0wbYmiZ33VkOx8X+vEO+2lRmwcyDGF4DxEDw0mIBFlm3K RqS6RDTm06ZDi7SlNFZKJx62nXAjzeazrSQoYo/2P/ISGMN++olNgeR0NxmiTd5/rzwY YcH3ECDQwcI07tCb0e+IM47wbW4sjt/hukxWO2bN9J0sPoopzmWivA4dudLUHUrEBI8L nIDKkecStyMxiypy8FvBAXqLUNKgqkBNTIUYY/QPouQNrScgmvF3x4RCQnsDpHAogZZw 5jYi+6G3lxrwcnX+FJwNvCS0jn3kb7g8V3WIh61xiAP0y8Ck9bYwxEeNq91fphwZ6phc +txg== X-Gm-Message-State: APjAAAVgY6H0k2NhAbK7kQdUd/NGYj42Zph1HxiEquZvoe8NAgZsiTSQ IZaWh6VsHwPeGgOY0LRmxackTEobKsA8bxPBYko= X-Received: by 2002:a2e:8016:: with SMTP id j22mr14020495ljg.24.1579567425227; Mon, 20 Jan 2020 16:43:45 -0800 (PST) MIME-Version: 1.0 References: <157952560001.1683545.16757917515390545122.stgit@toke.dk> In-Reply-To: From: Alexei Starovoitov Date: Mon, 20 Jan 2020 16:43:33 -0800 Message-ID: Subject: Re: [PATCH bpf-next v5 00/11] tools: Use consistent libbpf include paths everywhere To: Andrii Nakryiko Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , Andrii Nakryiko , Doug Ledford , Jason Gunthorpe , "David S. Miller" , Jakub Kicinski , Jesper Dangaard Brouer , John Fastabend , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Shuah Khan , Networking , bpf , open list , linux-rdma@vger.kernel.org, "open list:KERNEL SELFTEST FRAMEWORK" , Clang-Built-Linux ML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 20, 2020 at 2:21 PM Andrii Nakryiko wrote: > > On Mon, Jan 20, 2020 at 5:08 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > > > We are currently being somewhat inconsistent with the libbpf include pa= ths, > > which makes it difficult to move files from the kernel into an external > > libbpf-using project without adjusting include paths. > > > > Having the bpf/ subdir of $INCLUDEDIR in the include path has never bee= n a > > requirement for building against libbpf before, and indeed the libbpf p= kg-config > > file doesn't include it. So let's make all libbpf includes across the k= ernel > > tree use the bpf/ prefix in their includes. Since bpftool skeleton gene= ration > > emits code with a libbpf include, this also ensures that those can be u= sed in > > existing external projects using the regular pkg-config include path. > > > > This turns out to be a somewhat invasive change in the number of files = touched; > > however, the actual changes to files are fairly trivial (most of them a= re simply > > made with 'sed'). The series is split to make the change for one tool s= ubdir at > > a time, while trying not to break the build along the way. It is struct= ured like > > this: > > > > - Patch 1-3: Trivial fixes to Makefiles for issues I discovered while c= hanging > > the include paths. > > > > - Patch 4-8: Change the include directives to use the bpf/ prefix, and = updates > > Makefiles to make sure tools/lib/ is part of the include path, but wi= thout > > removing tools/lib/bpf > > > > - Patch 9-11: Remove tools/lib/bpf from include paths to make sure we d= on't > > inadvertently re-introduce includes without the bpf/ prefix. > > > > Changelog: > > > > v5: > > - Combine the libbpf build rules in selftests Makefile (using Andrii'= s > > suggestion for a make rule). > > - Re-use self-tests libbpf build for runqslower (new patch 10) > > - Formatting fixes > > > > v4: > > - Move runqslower error on missing BTF into make rule > > - Make sure we don't always force a rebuild selftests > > - Rebase on latest bpf-next (dropping patch 11) > > > > v3: > > - Don't add the kernel build dir to the runqslower Makefile, pass it = in from > > selftests instead. > > - Use libbpf's 'make install_headers' in selftests instead of trying = to > > generate bpf_helper_defs.h in-place (to also work on read-only file= systems). > > - Use a scratch builddir for both libbpf and bpftool when building in= selftests. > > - Revert bpf_helpers.h to quoted include instead of angled include wi= th a bpf/ > > prefix. > > - Fix a few style nits from Andrii > > > > v2: > > - Do a full cleanup of libbpf includes instead of just changing the > > bpf_helper_defs.h include. > > > > --- > > > > Looks good, it's a clear improvement on what we had before, thanks! > > It doesn't re-build bpftool when bpftool sources changes, but I think > it was like that even before, so no need to block on that. Would be > nice to have a follow up fixing that, though. $(wildcard > $(BPFTOOL_DIR)/*.[ch] $(BPFTOOL_DIR)/Makefile) should do it, same as > for libbpf. > > So, for the series: > > Acked-by: Andrii Nakryiko > Tested-by: Andrii Nakryiko Applied. Thanks