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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EACD9C433EF for ; Tue, 26 Apr 2022 16:10:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352823AbiDZQNI (ORCPT ); Tue, 26 Apr 2022 12:13:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46642 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244812AbiDZQNH (ORCPT ); Tue, 26 Apr 2022 12:13:07 -0400 Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0D1505581; Tue, 26 Apr 2022 09:09:59 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id r12so20609043iod.6; Tue, 26 Apr 2022 09:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=erYFw2u97tYKdbMKzqyt7/Xqd3qvZzbPh4jS2jb8UDE=; b=PhZvqktTmQr6aQbxoGlQo0TVdZt4+o6F+UzjuT8taO9vHUS7j6qotGpRt8qvxDTSrp q/hJndWVpA4mtlu7mnkXF8FpFO2ACQYQM21VOyvFyqqxaVssOw1ni+3nmzypL08ALJed FI3y2NkVx6le6puYitoPqdTW01TIVcJyEIOHa2F8sRqOsNzlkBKG3B5tt2Z+9tsHhqAr AuF458ZztRNqyJEZXYto8cW4ZVtC9RpDyrWQ0JlgCOwd7WT9KkWNK5TXyIto/iCHao1o IUpPunUfw/Lzzmk5DExoeuc/gE8zpRlrt1vMRzelwto9HzfNFIHrQ5ThZn81WXnXp1K0 3pbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=erYFw2u97tYKdbMKzqyt7/Xqd3qvZzbPh4jS2jb8UDE=; b=QOUyxPMVTClV334yAFN85592Vz2/TqAf9b1wduwE+WELihPdaRuK9sAQy1HtbAQltd adnZCs8wou6gTJursiqYw0jLcl6ldqSPihyI9d04ImCNdDeFimHyDsB6Tv7F9ezpOQNU XXCFOe5IK3VcQJfC55cnovGKmAow14PGh1ft+Hs1kGk37mpOHrIL7eNZtnppfUv4xd9S Wlk5nkrzpMWZ22XXSaF8KsSiNEBB/y5dtGZfEq/mlka9CGRpshLdtpz8qUbJJ52TnsiY vIBypBK5ZU+J+NitBjoL3hCB+jZDfzggmCqDOjFeRntF8NrlTaHCZfQ/uKwrle1IM1y5 OEpA== X-Gm-Message-State: AOAM530zbAZGBzXotwAYV7RWGs/UwJni5GvycxrCjsdNt1q13N/0TopD sOgdM2g8mJpxaKa0AbNMXFkJKXRWGipOiJGpUwg= X-Google-Smtp-Source: ABdhPJxN1vH3Y34DEJRqM9xhBuY+Iqd27t4QJbnKrirvnQg2TQ+uIrT6YQTsG+0s+UaB1jjQkzRMZqa9NCtLrZXM1y8= X-Received: by 2002:a05:6602:1592:b0:654:b130:2fa5 with SMTP id e18-20020a056602159200b00654b1302fa5mr9978759iow.33.1650989398540; Tue, 26 Apr 2022 09:09:58 -0700 (PDT) MIME-Version: 1.0 References: <20220423140058.54414-1-laoar.shao@gmail.com> In-Reply-To: From: Yafang Shao Date: Wed, 27 Apr 2022 00:09:22 +0800 Message-ID: Subject: Re: [PATCH bpf-next 0/4] bpf: Generate helpers for pinning through bpf object skeleton To: Andrii Nakryiko Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin Lau , Song Liu , Yonghong Song , john fastabend , KP Singh , Networking , bpf Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Tue, Apr 26, 2022 at 2:45 PM Andrii Nakryiko wrote: > > On Sat, Apr 23, 2022 at 7:01 AM Yafang Shao wrote: > > > > Currently there're helpers for allowing to open/load/attach BPF object > > through BPF object skeleton. Let's also add helpers for pinning through > > BPF object skeleton. It could simplify BPF userspace code which wants to > > pin the progs into bpffs. > > > > After this change, with command 'bpftool gen skeleton XXX.bpf.o', the > > helpers for pinning BPF prog will be generated in BPF object skeleton. > > > > The new helpers are named with __{pin, unpin}_prog, because it only pins > > bpf progs. If the user also wants to pin bpf maps, he can use > > LIBBPF_PIN_BY_NAME. > > API says it's pinning programs, but really it's trying to pin links. Actually it should be bpf_object__pin_skeleton_link(). > But those links might not even be created for non-auto-attachable > programs, and for others users might or might not set > .links. links. > > There are lots of questions about this new functionality... But the > main one is why do we need it? What does it bring that's hard to do > otherwise? > See also my replyment to Daniel[1]. For the FD-based bpf objects, the userspace code is similar, so we can abstract the userspace code into a common code, and then the developer doesn't need to write the userspace code any more (if he doesn't have some special userspace logical.). [1]. https://lore.kernel.org/bpf/CAEf4BzbhODOBrE=unLOUpo40uUYz72BJX-+uJobiwhF9VFSizQ@mail.gmail.com/T/#m32dfc6343f2b4fba980c62686b245cb6e0133c2f > > > > Yafang Shao (4): > > libbpf: Define DEFAULT_BPFFS > > libbpf: Add helpers for pinning bpf prog through bpf object skeleton > > bpftool: Fix incorrect return in generated detach helper > > bpftool: Generate helpers for pinning prog through bpf object skeleton > > > > tools/bpf/bpftool/gen.c | 18 ++++++++++- > > tools/lib/bpf/bpf_helpers.h | 2 +- > > tools/lib/bpf/libbpf.c | 61 ++++++++++++++++++++++++++++++++++++- > > tools/lib/bpf/libbpf.h | 10 ++++-- > > tools/lib/bpf/libbpf.map | 2 ++ > > 5 files changed, 88 insertions(+), 5 deletions(-) > > > > -- > > 2.17.1 > > -- Regards Yafang