Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp7972612rwl; Tue, 10 Jan 2023 07:34:47 -0800 (PST) X-Google-Smtp-Source: AMrXdXv0iVj25RRMAWByFnpsKA9xEj3besr0npyLOOyOVL+b28hZMdmPtMmg16mG2fc8F3QhEVXQ X-Received: by 2002:a05:6a20:1586:b0:9d:efd3:66c1 with SMTP id h6-20020a056a20158600b0009defd366c1mr97486599pzj.8.1673364887124; Tue, 10 Jan 2023 07:34:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673364887; cv=none; d=google.com; s=arc-20160816; b=LORAOtYMpoH36FxFfgxxDMfnjMybu35f9rjLwlKgBD9S9EdH0vN1vT9eqTt6P8BrQV eLkqKz02jUSAkVDvMxGVZCp0IOI6SI8JWcOJzpTKjIC36cUXVTBfUhLrFNIDXlzoYOvn +6HsPcLv83Xf5n6UnI/OuJpCAUEPpQjUi1L+VMiiusQ5WC7VtA0ttN9L2a4l8BLIHFto mx5n4ugQnyf1IJJ98ePqV4/lyWWPfwn57BgUCCTjqkJQEHYKvAACp6H6Aj5RFUaEZtdQ JZ8IFvTCNoqpsH4kWdPxZEe25vnwxyTtM4Dcz2ubiwtUQdDmgjmxRFZ30276puDTnSkR EzfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=TXaJTJRxqGuyUq1rarM/36rLMQoZn+yzUPSTA/mnl6I=; b=WFpQ2RsDrV/UQ64K7hsx84kGVOkHGNMDwcF0FbkonYyJSbbfw65GOx8PUtiTB337GG eR+CsqaqRR7UFOLweSXwrEg8dT8DyaAWLuX8Kp4eZJhatYA/i9/+UpYyfwtyNONnq8lb X2UhGzslAAzExEnSeZBmg8zLI7Qnox7y+cTIdS6goEqwfIf3Xp73XOPHB5xENWFEjlxL tdxGUnxXNoWBfBmIq6n1Rr/t8wxc+xZz/iGVdZWO6ylvopQ+ShnciKE/A3SoI0b/+6Lv Rp/Yk9QDCjL+6jzS37mULzPV3FAWU6aMC2ZeEg8yrbV/iWijzEG0bJ8THTZC3tcGkboM 73+g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=LuPtIDLf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id mw6-20020a17090b4d0600b002196cd830e6si11790802pjb.11.2023.01.10.07.34.40; Tue, 10 Jan 2023 07:34:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=LuPtIDLf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233982AbjAJOqb (ORCPT + 53 others); Tue, 10 Jan 2023 09:46:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56998 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230038AbjAJOqT (ORCPT ); Tue, 10 Jan 2023 09:46:19 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 946434FCED; Tue, 10 Jan 2023 06:46:18 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 38F5F61759; Tue, 10 Jan 2023 14:46:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67327C433F0; Tue, 10 Jan 2023 14:46:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673361977; bh=Jd8jGSPIFdj2DgSDZN8XQd2dUL3NZySQqoBtiIgILT8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LuPtIDLfHpPZOrBg2x3WkyoPCEG86KhTQLNGMS/w2biIGsXveRpQ61QSBHUKTzHzz +L60t5aJatwFjL+IDHRug4xxIJPiywQsMMzJ3YzxUCqLsXKCdVSICZTIfb1UdmHIit UqgGoqrx1Znla5Tg6S21Gc/XBHB1arP149+7Dxkv8TYmTaHiP9716uM8134lUx+DGv H2eMUiVROFTeqCF/12jpAxXQyJ5cqPxhNOedYWL889dGut2vGACAWDvk+oMRZQ3qdn tez0z3ZLbYL29RJaesPoFF3wW2qRt/JHC01cN6vBhmx1bV6JQfPDbEMU7LPTrsvvgl npbhgKKl+r+oA== Received: by quaco.ghostprotocols.net (Postfix, from userid 1000) id C53CC40468; Tue, 10 Jan 2023 11:46:14 -0300 (-03) Date: Tue, 10 Jan 2023 11:46:14 -0300 From: Arnaldo Carvalho de Melo To: Ian Rogers Cc: Jiri Olsa , Mike Leach , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, peterz@infradead.org, mingo@redhat.com, mark.rutland@arm.com, alexander.shishkin@linux.intel.com, namhyung@kernel.org Subject: Re: [PATCH v3 1/2] perf build: Properly guard libbpf includes Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Url: http://acmel.wordpress.com X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Tue, Jan 10, 2023 at 11:31:12AM -0300, Arnaldo Carvalho de Melo escreveu: > Em Mon, Jan 09, 2023 at 11:29:51AM -0800, Ian Rogers escreveu: > > On Mon, Jan 9, 2023 at 10:37 AM Ian Rogers wrote: > > > -int libbpf_register_prog_handler(const char *sec __maybe_unused, > > > - enum bpf_prog_type prog_type __maybe_unused, > > > - enum bpf_attach_type exp_attach_type > > > __maybe_unused, > > > - const struct > > > libbpf_prog_handler_opts *opts __maybe_unused) > > > +static int libbpf_register_prog_handler(const char *sec __maybe_unused, > > > + enum bpf_prog_type prog_type > > > __maybe_unused, > > > + enum bpf_attach_type > > > exp_attach_type __maybe_unused, > > > + const void *opts __maybe_unused) > > > { > > > pr_err("%s: not support, update libbpf\n", __func__); > > > return -ENOTSUP; > > > ``` > > > > > > There are some other fixes necessary too. I'll try to write the fuller > > > patch but I have no means for testing except for undefining > > > HAVE_LIBBPF_BPF_PROGRAM__SET_INSNS. > > > > So libbpf_prog_handler_opts is missing in the failing build, this > > points to a libbpf before 0.8. I'm somewhat concerned that to work > > around these linkage problems we're adding runtime errors - we may > > build but the functionality is totally crippled. Is it worth > > maintaining these broken builds or to just upfront fail the feature > > test? > Probably better to make the feature test disable bpf support while > emitting a warning that features such as a, b, and c won't we available. This would be the one-liner I think is appropriate for v6.2, ok? diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config index 9962ae23ab8c5868..5b87846759036f6f 100644 --- a/tools/perf/Makefile.config +++ b/tools/perf/Makefile.config @@ -589,6 +589,8 @@ ifndef NO_LIBELF $(call feature_check,libbpf-bpf_program__set_insns) ifeq ($(feature-libbpf-bpf_program__set_insns), 1) CFLAGS += -DHAVE_LIBBPF_BPF_PROGRAM__SET_INSNS + else + dummy := $(error Error: libbpf devel library needs to be >= 0.8.0 to build with LIBBPF_DYNAMIC, update or build statically with the version that comes with the kernel sources); endif $(call feature_check,libbpf-btf__raw_data) ifeq ($(feature-libbpf-btf__raw_data), 1)