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 423E2C38145 for ; Thu, 8 Sep 2022 22:03:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229647AbiIHWDN (ORCPT ); Thu, 8 Sep 2022 18:03:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32978 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229808AbiIHWDL (ORCPT ); Thu, 8 Sep 2022 18:03:11 -0400 Received: from mail-pg1-x54a.google.com (mail-pg1-x54a.google.com [IPv6:2607:f8b0:4864:20::54a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5BC2221E2A for ; Thu, 8 Sep 2022 15:03:08 -0700 (PDT) Received: by mail-pg1-x54a.google.com with SMTP id j3-20020a634a43000000b00429f2cb4a43so9750935pgl.0 for ; Thu, 08 Sep 2022 15:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date; bh=jmF3L7fdnaxbLGMrdwbUuIUSIsnbhXhFayKkpZwWlXk=; b=Dnw6Tz/e7ymx6XVTmlixF5PpwcZP8Dfsa/pvbvD5SquY/0NoDfbBztpaxNQS2IIZty XSmICVJ49J/ZG5Lk3EdvXOqDS8Sy3gkVfz8k0laK7ZNaB0fhNsEIxaW5eVWH5eyDdxCv nw14GnL12FbjvVTgnXncyQsZy2PNArkoga7VLu5ZxrSB6kerDQOoc66fWGwmS/Zu/I5t 3aCCjn9/6LHGNzINfuBgwKjYTWNvXj2/kwgrTAJDNHvP+E7Fm8tpy9T6XQGMtQ5brZR1 a05Clbl3D7RrM/u0RX12BTmO+LC54BbfcwGFaT0hRNdu8z5Pi1PVCTnuulE9ynWGm2a+ OXQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date; bh=jmF3L7fdnaxbLGMrdwbUuIUSIsnbhXhFayKkpZwWlXk=; b=DorSY1zJZZsL7GvEpzgw13ZLMJBOotAaRkhj2J8F53zmwS9WSee70VwiV2mS+4Xlvk qToee0Mdwu0w4AWcs2TGmET6yuJ/rSxIGo69UsmqBtSjqbi6ZJjW6I+2RerHb5ZUn5lG NpAyWCoS9vvSWDOJ2M/qn0hj6iCQEM1cGn40ooEgw/kCvqgFpyWJX3VgxwAZBHzOZMGj kkTy/HSba/wb6OP6WF1AJKOCcQj0Dz5FbqejKNc/aIw9VUjqHVKQlFVcA74Xl6sDBXza pG3tNws2d+SJr0mDR/u1UiGlehMxZy/Utt4bnksIgriaYvDaWzpUFQd7tMhu5N8cwlUo dWHg== X-Gm-Message-State: ACgBeo04yrjHbyNJFMWliGoAuPYfn7uUFTfdbfvqpV4XW74Kw6wnyc3H 6Ma/nx7YA4hHEVu2kw+T1xDsTwg= X-Google-Smtp-Source: AA6agR4XtsDA2L/TpFpjdi2qZPBQHf8Kfg0HT8msLvJ2IjAQMuAcNkBZQVkWTfkvqbczYInaxHMjgss= X-Received: from sdf.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5935]) (user=sdf job=sendgmr) by 2002:a17:903:248:b0:172:7520:db04 with SMTP id j8-20020a170903024800b001727520db04mr10968865plh.99.1662674587241; Thu, 08 Sep 2022 15:03:07 -0700 (PDT) Date: Thu, 8 Sep 2022 15:03:05 -0700 In-Reply-To: <20220908183952.3438815-1-mj@hunetr.com> Mime-Version: 1.0 References: <20220908183952.3438815-1-mj@hunetr.com> Message-ID: Subject: Re: [PATCH] bpftool: output map/prog indices on `gen skeleton` From: sdf@google.com To: Marcelo Juchem Cc: bpf@vger.kernel.org, Marcelo Juchem Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On 09/08, Marcelo Juchem wrote: > The skeleton generated by `bpftool` makes it easy to attach and load bpf > objects as a whole. Some BPF programs are not directly portable across > kernel > versions, though, and require some cherry-picking on which programs to > load/attach. The skeleton makes this cherry-picking possible, but not > entirely > friendly in some cases. > For example, an useful feature is `attach_with_fallback` so that one > program can be attempted, and fallback programs tried subsequently until > one works (think `tcp_recvmsg` interface changing on kernel 5.19). > Being able to represent a set of probes programatically in a way that is > both > descriptive, compile-time validated, runtime efficient and custom library > friendly is quite desirable for application developers. A very simple way > to > represent a set of probes is with an array of indices. > This patch creates a couple of enums under the `__cplusplus` section to > represent the program and map indices inside the skeleton object, that > can be > used to refer to the proper program/map object. > This is the code generated for the `__cplusplus` section of > `profiler.skel.h`: > ``` > enum map_idxs: size_t { > events = 0, > fentry_readings = 1, > accum_readings = 2, > counts = 3, > rodata = 4 > }; > enum prog_idxs: size_t { > fentry_XXX = 0, > fexit_XXX = 1 > }; > static inline struct profiler_bpf *open(const struct > bpf_object_open_opts *opts = nullptr); > static inline struct profiler_bpf *open_and_load(); > static inline int load(struct profiler_bpf *skel); > static inline int attach(struct profiler_bpf *skel); > static inline void detach(struct profiler_bpf *skel); > static inline void destroy(struct profiler_bpf *skel); > static inline const void *elf_bytes(size_t *sz); > ``` > --- > src/gen.c | 32 ++++++++++++++++++++++++++++++++ > 1 file changed, 32 insertions(+) > diff --git a/src/gen.c b/src/gen.c > index 7070dcf..7e28dc7 100644 > --- a/src/gen.c > +++ b/src/gen.c > @@ -1086,6 +1086,38 @@ static int do_skeleton(int argc, char **argv) > \n\ > \n\ > #ifdef __cplusplus \n\ > + " > + ); > + [..] > + { > + size_t i = 0; > + printf("\tenum map_index: size_t {"); > + bpf_object__for_each_map(map, obj) { > + if (!get_map_ident(map, ident, sizeof(ident))) > + continue; > + if (i) { > + printf(","); > + } > + printf("\n\t\t%s = %lu", ident, i); > + ++i; > + } > + printf("\n\t};\n"); > + } > + { > + size_t i = 0; > + printf("\tenum prog_index: size_t {"); > + bpf_object__for_each_program(prog, obj) { > + if (i) { > + printf(","); > + } > + printf("\n\t\t%s = %lu", bpf_program__name(prog), i); > + ++i; > + } > + printf("\n\t};\n"); > + } I might be missing something, but what prevents you from calling these on the skeleton's bpf_object? skel = xxx__open(); bpf_object__for_each_map(map, skel->obj) { // do whatever you want here to test whether it's loadable or not } // same for bpf_object__for_each_program xxx__load(skel); How do these new enums help?