From patchwork Tue Feb 8 12:06:46 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Quentin Monnet X-Patchwork-Id: 12738578 X-Patchwork-Delegate: bpf@iogearbox.net Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D9883C433FE for ; Tue, 8 Feb 2022 12:07:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347535AbiBHMG5 (ORCPT ); Tue, 8 Feb 2022 07:06:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49752 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235596AbiBHMG4 (ORCPT ); Tue, 8 Feb 2022 07:06:56 -0500 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 38846C03FECE for ; Tue, 8 Feb 2022 04:06:55 -0800 (PST) Received: by mail-ej1-x62c.google.com with SMTP id fy20so2794472ejc.0 for ; Tue, 08 Feb 2022 04:06:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isovalent-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=8fg00wYmgzGrMExRIHkll4yjvNxK+wTB/UV5qRmgneg=; b=cV8bIyZrbx+gtv+N/d+5xTcHKMz9Fei/XdNdWQvam5P2LKa279Fub7hBvDzUMki275 d06x0RMMCAU8i3FiOpwq/CehPjDthqWHEuKcOhPtSsE5SK7VJHkajSSsv7AJMSVVz7vZ goT3d4jlT67noDZxR0FyokVepsSqZ06Bkb7FKq1vd+ef9zWXY1MDu7PFIEYJpRfWRTEV WHOjjEMCzF1F0JzrGfs51IG0zdw+v2z9kcE6ZkycrYKN+pXhkhs1W4VlfYsnHSxjFbCM qCcF1GJ1xPKpDtr84EGA8edfU2ZfTyJtXuyPiwWtZtTkGLVpR3XWJw4CgqkeBxcH6bOR XJQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=8fg00wYmgzGrMExRIHkll4yjvNxK+wTB/UV5qRmgneg=; b=xvLo2EZgRteYawJqI3YzwfOjetGbaFmG8+GxaEPhuHZ6NFek7uMhZpGGQusjbvs/ah jKsrM49xUKpno9fEjtmen7Wcto87YYRiM8ifzvvos3IHiZW2p0dJxykGkO+3TOjngy86 bWS4Q1ueibFyV9b6k6V1U4gUwb1HCWuuoYmRXWDrXhk3zms85qWTyyuH35NxDwpq+C9F f4bCP7ks6UmeVZkZcC3EYklDO/gWnKquZ5pJPz78wlMocQM+xvSnT1MzEvrV6t3LnVJF 9RQc4/IgfmwUXNYYCYLNvPbVgsmld8LQ7nRLdrG8CF2aMSnD2H+qHTfCvfT5hMBTu1oy U8nA== X-Gm-Message-State: AOAM532Tba5qAy7mV2/eUscT161JR5TGUWBza43SbkcrA1mszX+4Cge6 yHiD0cPsASNjG174JXbYvjE8oQ== X-Google-Smtp-Source: ABdhPJyuvMBdSe2bNtslbnVFFXVnDfWJlLAybtE1CDhZ/H3kXJr70siSdBEvfiqjaQYT5wPW41txNQ== X-Received: by 2002:a17:906:7383:: with SMTP id f3mr1212371ejl.687.1644322013816; Tue, 08 Feb 2022 04:06:53 -0800 (PST) Received: from localhost.localdomain ([149.86.77.242]) by smtp.gmail.com with ESMTPSA id m17sm5567351edr.62.2022.02.08.04.06.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Feb 2022 04:06:53 -0800 (PST) From: Quentin Monnet To: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko Cc: netdev@vger.kernel.org, bpf@vger.kernel.org, Quentin Monnet Subject: [PATCH bpf-next v2 1/3] bpftool: Add libbpf's version number to "bpftool version" output Date: Tue, 8 Feb 2022 12:06:46 +0000 Message-Id: <20220208120648.49169-2-quentin@isovalent.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220208120648.49169-1-quentin@isovalent.com> References: <20220208120648.49169-1-quentin@isovalent.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: bpf@iogearbox.net To help users check what version of libbpf is being used with bpftool, print the number along with bpftool's own version number. Output: $ ./bpftool version ./bpftool v5.16.0 using libbpf v0.7 features: libbfd, libbpf_strict, skeletons $ ./bpftool version --json --pretty { "version": "5.16.0", "libbpf_version": "0.7", "features": { "libbfd": true, "libbpf_strict": true, "skeletons": true } } Note that libbpf_version_string() does note return the patch number. Signed-off-by: Quentin Monnet --- tools/bpf/bpftool/Documentation/common_options.rst | 13 +++++++------ tools/bpf/bpftool/main.c | 4 ++++ 2 files changed, 11 insertions(+), 6 deletions(-) diff --git a/tools/bpf/bpftool/Documentation/common_options.rst b/tools/bpf/bpftool/Documentation/common_options.rst index 908487b9c2ad..c88e4c6a06d2 100644 --- a/tools/bpf/bpftool/Documentation/common_options.rst +++ b/tools/bpf/bpftool/Documentation/common_options.rst @@ -4,12 +4,13 @@ Print short help message (similar to **bpftool help**). -V, --version - Print version number (similar to **bpftool version**), and optional - features that were included when bpftool was compiled. Optional - features include linking against libbfd to provide the disassembler - for JIT-ted programs (**bpftool prog dump jited**) and usage of BPF - skeletons (some features like **bpftool prog profile** or showing - pids associated to BPF objects may rely on it). + Print bpftool's version number (similar to **bpftool version**), the + number of the version of libbpf in use, and optional features that + were included when bpftool was compiled. Optional features include + linking against libbfd to provide the disassembler for JIT-ted + programs (**bpftool prog dump jited**) and usage of BPF skeletons + (some features like **bpftool prog profile** or showing pids + associated to BPF objects may rely on it). -j, --json Generate JSON output. For commands that cannot produce JSON, this diff --git a/tools/bpf/bpftool/main.c b/tools/bpf/bpftool/main.c index 490f7bd54e4c..6265ac5bcf4e 100644 --- a/tools/bpf/bpftool/main.c +++ b/tools/bpf/bpftool/main.c @@ -89,6 +89,9 @@ static int do_version(int argc, char **argv) jsonw_name(json_wtr, "version"); jsonw_printf(json_wtr, "\"%s\"", BPFTOOL_VERSION); + jsonw_name(json_wtr, "libbpf_version"); + /* Offset by one to skip the "v" prefix */ + jsonw_printf(json_wtr, "\"%s\"", libbpf_version_string() + 1); jsonw_name(json_wtr, "features"); jsonw_start_object(json_wtr); /* features */ @@ -102,6 +105,7 @@ static int do_version(int argc, char **argv) unsigned int nb_features = 0; printf("%s v%s\n", bin_name, BPFTOOL_VERSION); + printf("using libbpf %s\n", libbpf_version_string()); printf("features:"); if (has_libbfd) { printf(" libbfd"); From patchwork Tue Feb 8 12:06:47 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Quentin Monnet X-Patchwork-Id: 12738579 X-Patchwork-Delegate: bpf@iogearbox.net Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4AA66C433F5 for ; Tue, 8 Feb 2022 12:07:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346855AbiBHMHC (ORCPT ); Tue, 8 Feb 2022 07:07:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49766 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347519AbiBHMG5 (ORCPT ); Tue, 8 Feb 2022 07:06:57 -0500 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8CAAFC03FECA for ; Tue, 8 Feb 2022 04:06:56 -0800 (PST) Received: by mail-ej1-x631.google.com with SMTP id k25so51182967ejp.5 for ; Tue, 08 Feb 2022 04:06:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isovalent-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=iTdMXnmtGPLZRSvlL1IcNtJZpPvHU3gWUTLzYfE+SxE=; b=SAYY6wGOIVD0AIl6XkKbe6OEJ1zPsZEZ4paudU5iBURPJ5YLioi9K3UQxb3qp0aSAn U31d/hQTPa0wjQt7YkxNG2KtRAOYzB3GFkNJYy8F5atoQ6ncMfduXadUU+N8+4LnjfPs tbXZrMnyohTJQmA3frAxExswKsA+5wJ90T32qFTbaWBUJHisP1Fl0gB5t7hiHyWa7KU8 8UOvrPuc5+/qdtJOnnP+AzX2TanFV5xC8JXFg3tNG6rWkHY1Iayhjej8ZQZSsEAalgGy Z2x1hm62Itp65O4S0KM51QV/yDyi+w7vn0+JFnwljzgtSlQqJFDPYUKsU+TEFeXfHQZt kOSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=iTdMXnmtGPLZRSvlL1IcNtJZpPvHU3gWUTLzYfE+SxE=; b=aGAElPhbOLvpyGySfllloF6jzYNBIMZL6TGCcfYhEWcRiD6p0ujwtvO56OwiWH+JmT a6I5dXAIYrTuGN6OtkFsSz9GI4DX6tHWJnrHwNu7XjlfUcqvCZ1dAcRdEiFWYlq8njFO O7vkVH2thkdNFaioFp/xcihrUMrPMhl58jogDd1KaiILQgHFBM29nuBEFd9LHAxpNA88 0Ybo69QAOyrHz85sztgyfbejRSgqecW3CpgD14KChHwbUnoCKXVgPgDd6w8PbZ7kpPIe FGSakcFhJTW7B1sC3LyApUqgM5e/Zq2QL4AGluumBQLCQ1GHzhAd1buXws4deaPAD5nI TAmQ== X-Gm-Message-State: AOAM533c16OMmdUUhL3r4PxiB1gNSCAvHMzQ3rQOPZfZqs0Nq9S6rrJW kXDNv3tMpLJEcpIdYYZ/e3KJ12dQQpcZkg== X-Google-Smtp-Source: ABdhPJwMsCI2qbWp1E5WT/ejbpHBceAKMrBZ23qpp1k9dfTOiIX3ekzZv1JnbNt8pXkn5EDuyLUUBg== X-Received: by 2002:a17:907:62a9:: with SMTP id nd41mr3471216ejc.50.1644322015107; Tue, 08 Feb 2022 04:06:55 -0800 (PST) Received: from localhost.localdomain ([149.86.77.242]) by smtp.gmail.com with ESMTPSA id m17sm5567351edr.62.2022.02.08.04.06.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Feb 2022 04:06:54 -0800 (PST) From: Quentin Monnet To: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko Cc: netdev@vger.kernel.org, bpf@vger.kernel.org, Quentin Monnet Subject: [PATCH bpf-next v2 2/3] libbpf: Add "libbpversion" make target to print version Date: Tue, 8 Feb 2022 12:06:47 +0000 Message-Id: <20220208120648.49169-3-quentin@isovalent.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220208120648.49169-1-quentin@isovalent.com> References: <20220208120648.49169-1-quentin@isovalent.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: bpf@iogearbox.net Add a target to libbpf's Makefile to print its version number, in a similar way to what running "make kernelversion" at the root of the repository does. This is to avoid re-implementing the parsing of the libbpf.map file in case some other tools want to extract the version of the libbpf sources they are using. Signed-off-by: Quentin Monnet --- tools/lib/bpf/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile index b8b37fe76006..91136623edf9 100644 --- a/tools/lib/bpf/Makefile +++ b/tools/lib/bpf/Makefile @@ -108,6 +108,9 @@ MAKEOVERRIDES= all: +libbpfversion: + @echo $(LIBBPF_VERSION) + export srctree OUTPUT CC LD CFLAGS V include $(srctree)/tools/build/Makefile.include From patchwork Tue Feb 8 12:06:48 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Quentin Monnet X-Patchwork-Id: 12738580 X-Patchwork-Delegate: bpf@iogearbox.net Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4ED2EC433FE for ; Tue, 8 Feb 2022 12:07:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348221AbiBHMHG (ORCPT ); Tue, 8 Feb 2022 07:07:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49798 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347695AbiBHMG7 (ORCPT ); Tue, 8 Feb 2022 07:06:59 -0500 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1A036C03FECF for ; Tue, 8 Feb 2022 04:06:58 -0800 (PST) Received: by mail-ej1-x633.google.com with SMTP id o12so51579575eju.13 for ; Tue, 08 Feb 2022 04:06:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isovalent-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=bysXayoj/ZOqXC0/8UAT3GEQ7MEmhAEIOcxkwiZ3yAY=; b=VQMyTU4CXnn06uzQHW3sjNfiXj1subUzOFgdW3kbOYxPbFUPR9AUYedox4V4h5j/jS 3FmyJ+OOEaQ5VY3JlpYojxUBYuAJ14tPfw/k9FTfIPkwPhUudUdsZqs8U8cRuvw12K3/ p9Kv/eL1NLkgHE7x5h5nPetQuIU2o4hHyBFd7mNBIvaeLGz5RUE4k4myHh8eAf+j89OA E1B6ukeH3zf8ugb6fv9xUTxGKzP/+2YQKqGPqzdGGPng+njUKQPwKWaNE1Pj5UezghLs jF0BHvJF02bn00KPZMEKQqAe8TvEhIr3jnH8DEUkNL7Hn/bmE2oaFrER5wOCNP7bTA+C Av7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=bysXayoj/ZOqXC0/8UAT3GEQ7MEmhAEIOcxkwiZ3yAY=; b=0ZqTYRZ7XZhyCiX71l+kwKkbkBgFZ37oI6xOKyIrtvrB10A2wFqfjAwNiMozvpfxk0 1ngH2jfoI6iGDzz1lHCpJ1saSvN+5+3TElzK0/I/QpD5ntaEkHEGkAL0oY7bPfN6bq02 fq63LycI4ahx/1VIsGDZUxM1tH9VLiFg8HzAS2NACypKyWwPXTv5dad5MmU7Mgeqk4xz Vi1Wb9EV1ErEtPz8qWQWktScANZf86Q+3k1/vSj+ZDlfRpNR7rhaGW8RUm5kCSmBHdeM vg4WlhVPJexCNSmsRaByPh4E1f6XfczLwPLBHN8vxQr2o6BFy98//4xqOkIxBRbXAeep bCeg== X-Gm-Message-State: AOAM531H5iwZzO/uL8ZDNtaae0qJgTOn+es7uK6SacELQ8jRv1wfbLGq rHNoHAqnX4kow5JfJkIN0Bowpw== X-Google-Smtp-Source: ABdhPJy1VMXQiImoWz6SJVctnTicPlW8qYp1+ulx7E1TdRYZI0rTwKDFz0yENg3CU95v+/g4MAvdRQ== X-Received: by 2002:a17:907:7f0e:: with SMTP id qf14mr3479255ejc.152.1644322016601; Tue, 08 Feb 2022 04:06:56 -0800 (PST) Received: from localhost.localdomain ([149.86.77.242]) by smtp.gmail.com with ESMTPSA id m17sm5567351edr.62.2022.02.08.04.06.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Feb 2022 04:06:56 -0800 (PST) From: Quentin Monnet To: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko Cc: netdev@vger.kernel.org, bpf@vger.kernel.org, Quentin Monnet Subject: [PATCH bpf-next v2 3/3] bpftool: Update versioning scheme, align on libbpf's version number Date: Tue, 8 Feb 2022 12:06:48 +0000 Message-Id: <20220208120648.49169-4-quentin@isovalent.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220208120648.49169-1-quentin@isovalent.com> References: <20220208120648.49169-1-quentin@isovalent.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: bpf@iogearbox.net Since the notion of versions was introduced for bpftool, it has been following the version number of the kernel (using the version number corresponding to the tree in which bpftool's sources are located). The rationale was that bpftool's features are loosely tied to BPF features in the kernel, and that we could defer versioning to the kernel repository itself. But this versioning scheme is confusing today, because a bpftool binary should be able to work with both older and newer kernels, even if some of its recent features won't be available on older systems. Furthermore, if bpftool is ported to other systems in the future, keeping a Linux-based version number is not a good option. Looking at other options, we could either have a totally independent scheme for bpftool, or we could align it on libbpf's version number (with an offset on the major version number, to avoid going backwards). The latter comes with a few drawbacks: - We may want bpftool releases in-between two libbpf versions. We can always append pre-release numbers to distinguish versions, although those won't look as "official" as something with a proper release number. But at the same time, having bpftool with version numbers that look "official" hasn't really been an issue so far. - If no new feature lands in bpftool for some time, we may move from e.g. 6.7.0 to 6.8.0 when libbpf levels up and have two different versions which are in fact the same. - Following libbpf's versioning scheme sounds better than kernel's, but ultimately it doesn't make too much sense either, because even though bpftool uses the lib a lot, its behaviour is not that much conditioned by the internal evolution of the library (or by new APIs that it may not use). Having an independent versioning scheme solves the above, but at the cost of heavier maintenance. Developers will likely forget to increase the numbers when adding features or bug fixes, and we would take the risk of having to send occasional "catch-up" patches just to update the version number. Based on these considerations, this patch aligns bpftool's version number on libbpf's. This is not a perfect solution, but 1) it's certainly an improvement over the current scheme, 2) the issues raised above are all minor at the moment, and 3) we can still move to an independent scheme in the future if we realise we need it. Given that libbpf is currently at version 0.7.0, and bpftool, before this patch, was at 5.16, we use an offset of 6 for the major version, bumping bpftool to 6.7.0. It remains possible to manually override the version number by setting BPFTOOL_VERSION when calling make. Signed-off-by: Quentin Monnet --- Contrarily to the previous discussion and to what the first patch of the set does, I chose not to use the libbpf_version_string() API from libbpf to compute the version for bpftool. There were three reasons for that: - I don't feel comfortable having bpftool's version number computed at runtime. Somehow it really feels like we should now it when we compile it. We link statically against libbpf today, but if we were to support dynamic linking in the future we may forget to update and would have bpftool's version changing based on the libbpf version installed beside it, which does not make sense. - We cannot get the patch version for libbpf, the current API only returns the major and minor version numbers (we could fix it, although I'm not sure if desirable to expose the patch number). - I found it less elegant to compute the version strings in the code, which meant malloc() and error handling just for printing a version number, and having a separate case for when $(BPFTOOL_VERSION) is defined, whereas passing a macro from the Makefile makes things straightforwards. --- tools/bpf/bpftool/Makefile | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile index 83369f55df61..8dd30abff3d9 100644 --- a/tools/bpf/bpftool/Makefile +++ b/tools/bpf/bpftool/Makefile @@ -7,14 +7,21 @@ srctree := $(patsubst %/,%,$(dir $(srctree))) srctree := $(patsubst %/,%,$(dir $(srctree))) endif +BPF_DIR = $(srctree)/tools/lib/bpf + +# bpftool's version is libbpf's with a fixed offset for the major version. +# This is because bpftool's version was higher than libbpf's when we adopted +# this scheme. +BPFTOOL_MAJOR_OFFSET := 6 +LIBBPF_VERSION := $(shell make -r --no-print-directory -sC $(BPF_DIR) libbpfversion) +BPFTOOL_VERSION ?= $(shell lv="$(LIBBPF_VERSION)"; echo "$$((${lv%%.*} + $(BPFTOOL_MAJOR_OFFSET))).$${lv#*.}") + ifeq ($(V),1) Q = else Q = @ endif -BPF_DIR = $(srctree)/tools/lib/bpf - ifneq ($(OUTPUT),) _OUTPUT := $(OUTPUT) else @@ -39,10 +46,6 @@ LIBBPF_BOOTSTRAP := $(LIBBPF_BOOTSTRAP_OUTPUT)libbpf.a LIBBPF_INTERNAL_HDRS := $(addprefix $(LIBBPF_HDRS_DIR)/,hashmap.h nlattr.h) LIBBPF_BOOTSTRAP_INTERNAL_HDRS := $(addprefix $(LIBBPF_BOOTSTRAP_HDRS_DIR)/,hashmap.h) -ifeq ($(BPFTOOL_VERSION),) -BPFTOOL_VERSION := $(shell make -rR --no-print-directory -sC ../../.. kernelversion) -endif - $(LIBBPF_OUTPUT) $(BOOTSTRAP_OUTPUT) $(LIBBPF_BOOTSTRAP_OUTPUT) $(LIBBPF_HDRS_DIR) $(LIBBPF_BOOTSTRAP_HDRS_DIR): $(QUIET_MKDIR)mkdir -p $@