From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 210D1CA9ECF for ; Fri, 1 Nov 2019 09:16:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EB4B32054F for ; Fri, 1 Nov 2019 09:16:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728226AbfKAJQ5 convert rfc822-to-8bit (ORCPT ); Fri, 1 Nov 2019 05:16:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36284 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728206AbfKAJQ5 (ORCPT ); Fri, 1 Nov 2019 05:16:57 -0400 Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A703F59449 for ; Fri, 1 Nov 2019 09:16:56 +0000 (UTC) Received: by mail-lf1-f72.google.com with SMTP id o140so1905949lff.18 for ; Fri, 01 Nov 2019 02:16:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=Dkl3aHb5bKrEXW75qkROq0EGnFR82jvIZST+34q38vQ=; b=qR/NGezbLHYj8N9Vrxz4p/GnBENmoDscFj4UmZ68w29sHwaWgaYGHnmH7EPcmnqp/w 6QQ8CZ7v13JjU5yijKA1d27Q6CrArKz2E2BOvYgA0Np92PQeSfWYWapxBzSc3s7Z9vME p9b5yxPIpd+N9IRlSHGZ3OSe2lZjibA7/76Ut1BBjNrW0ku6HA/D2VaDxJ0LKltgPsul fNko5CeCDaE/fNruLc9Dx52GURhqsIgKjD6THesVBhrtipM2cqWURI4WrT0kWl5qFzTy SQJObKlqfQpRfLInVL1ygXAPjHdU8gJ4nqRKe7UZ1fWp/ASLnLGq7zOB8sgZG6B30IPk /xwA== X-Gm-Message-State: APjAAAXoLLV7dHnIpXy59UYBafh6fYxH5jPawJxeN+AvQyStai8FLa2s NaMaUgCxE74df1QSByiyDB8yl3USWaqvq6CVCdrdu7MJ+D9faWeJknusYD7Wu5xNb5PYgtalWw9 3iHXnfelTZwzj X-Received: by 2002:a2e:3807:: with SMTP id f7mr7518768lja.241.1572599813286; Fri, 01 Nov 2019 02:16:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqxFk5cohwcAac9ROKmVcbyZ06Unn9LDLz/uVc6cFTwxopCUrWZXfy4+5auWRTX485e2Ep6o2Q== X-Received: by 2002:a2e:3807:: with SMTP id f7mr7518742lja.241.1572599813038; Fri, 01 Nov 2019 02:16:53 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk ([2a00:7660:6da:443::2]) by smtp.gmail.com with ESMTPSA id u10sm641296lfn.48.2019.11.01.02.16.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Nov 2019 02:16:51 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id E28961818B5; Fri, 1 Nov 2019 10:16:50 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Alexei Starovoitov , Jiri Olsa Cc: =?utf-8?B?QmrDtnJuIFTDtnBlbA==?= , Magnus Karlsson , Magnus Karlsson , =?utf-8?B?QmrDtnJuIFTDtnBlbA==?= , Alexei Starovoitov , Daniel Borkmann , Network Development , Jonathan Lemon , bpf , degeneloy@gmail.com, John Fastabend Subject: Re: [PATCH bpf-next v3] libbpf: fix compatibility for kernels without need_wakeup In-Reply-To: References: <87lft1ngtn.fsf@toke.dk> <87imo5ng7w.fsf@toke.dk> <87d0ednf0t.fsf@toke.dk> <20191031174208.GC2794@krava> <20191031191815.GD2794@krava> X-Clacks-Overhead: GNU Terry Pratchett Date: Fri, 01 Nov 2019 10:16:50 +0100 Message-ID: <87tv7olzwd.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org Alexei Starovoitov writes: > On Thu, Oct 31, 2019 at 12:18 PM Jiri Olsa wrote: >> > >> > yes. older vmlinux and newer installed libbpf.so >> > or any version of libbpf.a that is statically linked into apps >> > is something that libbpf code has to support. >> > The server can be rebooted into older than libbpf kernel and >> > into newer than libbpf kernel. libbpf has to recognize all these >> > combinations and work appropriately. >> > That's what backward and forward compatibility is. >> > That's what makes libbpf so difficult to test, develop and code review. >> > What that particular server has in /usr/include is irrelevant. >> >> sure, anyway we can't compile following: >> >> tredaell@aldebaran ~ $ echo "#include " | gcc -x c - >> In file included from :1: >> /usr/include/bpf/xsk.h: In function ‘xsk_ring_prod__needs_wakeup’: >> /usr/include/bpf/xsk.h:82:21: error: ‘XDP_RING_NEED_WAKEUP’ undeclared (first use in this function) >> 82 | return *r->flags & XDP_RING_NEED_WAKEUP; >> ... >> >> XDP_RING_NEED_WAKEUP is defined in kernel v5.4-rc1 (77cd0d7b3f257fd0e3096b4fdcff1a7d38e99e10). >> XSK_UNALIGNED_BUF_ADDR_MASK and XSK_UNALIGNED_BUF_OFFSET_SHIFT are defined in kernel v5.4-rc1 (c05cd3645814724bdeb32a2b4d953b12bdea5f8c). >> >> with: >> kernel-headers-5.3.6-300.fc31.x86_64 >> libbpf-0.0.5-1.fc31.x86_64 >> >> if you're saying this is not supported, I guess we could be postponing >> libbpf rpm releases until we have the related fedora kernel released > > why? github/libbpf is the source of truth for building packages > and afaik it builds fine. > >> or how about inluding uapi headers in libbpf-devel.. but that might >> actualy cause more confusion > > Libraries (libbpf or any other) should not install headers that > typically go into /usr/include/ > if_xdp.h case is not unique. > We'll surely add another #define, enum, etc to uapi/linux/bpf.h tomorrow. > And we will not copy paste these constants and types into tools/lib/bpf/. > In kernel tree libbpf development is using kernel tree headers. > No problem there for libbpf developers. > Packages are built out of github/libbpf that has a copy of uapi headers > necessary to create packages. > No problem there for package builders either. > But libbpf package is not going to install those uapi headers. > libbpf package installs only libbpf own headers (like libbpf.h) > The users that want to build against the latest libbpf package need > to install corresponding uapi headers package. > I don't think such dependency is specified in rpm scripts. > May be it is something to fix? Or may be not. > Some folks might not want to update all of /usr/include to bring libbpf-devel. > Then it would be their responsibility to get fresh /usr/include headers. We can certainly tie libbpf to the kernel version. The obvious way to do that is to just ship the version of libbpf that's in the kernel tree of whatever kernel version the distro ships. But how will we handle bugfixes, then? You've explicitly stated that libbpf gets no bugfixes outside of bpf-next... -Toke