netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Jakub Kicinski <jakub.kicinski@netronome.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	netdev@vger.kernel.org, bpf@vger.kernel.org,
	oss-drivers@netronome.com
Subject: Re: [PATCH bpf-next 3/5] tools: libbpf: add a correctly named define for map iteration
Date: Wed, 27 Feb 2019 19:49:10 -0800	[thread overview]
Message-ID: <CAEf4BzZuOeUXKUmMqukQm2M1eTnX2=JwkNyfwF5FvbMEuby9BQ@mail.gmail.com> (raw)
In-Reply-To: <20190228024715.ijjki2fleuunxydn@ast-mbp>

On Wed, Feb 27, 2019 at 6:47 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Wed, Feb 27, 2019 at 03:57:03PM -0800, Jakub Kicinski wrote:
> > On Wed, 27 Feb 2019 15:47:56 -0800, Andrii Nakryiko wrote:
> > > On Wed, Feb 27, 2019 at 3:31 PM Jakub Kicinski
> > > <jakub.kicinski@netronome.com> wrote:
> > > >
> > > > For historical reasons the helper to loop over maps in an object
> > > > is called bpf_map__for_each while it really should be called
> > > > bpf_object__for_each_map.  Rename and add a correctly named
> > > > define for backward compatibility.
> > >
> > > Seems like there are at least 3 more functions that are not named correctly:
> > > - __bpf_map__iter (__bpf_object__iter_map?)
> > > - bpf_map__next (=> bpf_object__next_map?)
> > > - bpf_map__prev (=> bpf_object__prev_map?)
> > >
> > > Let's rename them as well?
> >
> > At least those are consistently named between programs and maps.
>
> I think this patch makes naming consistent enough.
>
> > I'm happy to do the rename if we don't need backward compat, seems
> > a little much to add aliases?
> >
> > > > Switch all in-tree users to the correct name (Quentin).
> > > >
> > > > Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> > > > Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
> >
> > > > diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> > > > index 6c0168f8bba5..b4652aa1a58a 100644
> > > > --- a/tools/lib/bpf/libbpf.h
> > > > +++ b/tools/lib/bpf/libbpf.h
> > > > @@ -278,10 +278,11 @@ bpf_object__find_map_by_offset(struct bpf_object *obj, size_t offset);
> > > >
> > > >  LIBBPF_API struct bpf_map *
> > > >  bpf_map__next(struct bpf_map *map, struct bpf_object *obj);
> > > > -#define bpf_map__for_each(pos, obj)            \
> > > > +#define bpf_object__for_each_map(pos, obj)             \
> > > >         for ((pos) = bpf_map__next(NULL, (obj));        \
> > > >              (pos) != NULL;                             \
> > > >              (pos) = bpf_map__next((pos), (obj)))
> > > > +#define bpf_map__for_each bpf_object__for_each_map
> > >
> > > Should we get rid of this as well, instead of accumulating cruft?
> >
> > Well, we did some gymnastics in the past to maintain backward compat,
> > I thought we do need it..?
>
> We do need to keep backward compat.
> This line is necessary.
>
> imo this set looks good to me as-is.
>

bpf_map__next/prev and bpf_program__next/prev convention feels a bit
weird, they fill more like methods of bpf_object rather than methods
of bpf_map and bpf_program, but I can understand why we might want to
preserve them.

Would it make sense to still add bpf_object__{next,prev}_{map,program}
(with struct bpf_object as a first arg) and just call them from
bpf_{map,program}__{next,prev}? That way we'll have consistent naming
that follows libbpf's own naming guidelines and we'll preserve
backwards compatibility? We can do that in follow up patches, if at
all, so I'll ack this patch.


Acked-by: Andrii Nakryiko <andriin@fb.com>

  reply	other threads:[~2019-02-28  3:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-27 23:30 [PATCH bpf-next 0/5] samples: bpf: start effort to get rid of bpf_load Jakub Kicinski
2019-02-27 23:30 ` [PATCH bpf-next 1/5] samples: bpf: force IPv4 in ping Jakub Kicinski
2019-02-28  0:18   ` Andrii Nakryiko
2019-02-27 23:30 ` [PATCH bpf-next 2/5] samples: bpf: remove load_sock_ops in favour of bpftool Jakub Kicinski
2019-02-28  0:20   ` Andrii Nakryiko
2019-02-27 23:30 ` [PATCH bpf-next 3/5] tools: libbpf: add a correctly named define for map iteration Jakub Kicinski
2019-02-27 23:47   ` Andrii Nakryiko
2019-02-27 23:57     ` Jakub Kicinski
2019-02-28  0:09       ` Andrii Nakryiko
2019-02-28  2:47       ` Alexei Starovoitov
2019-02-28  3:49         ` Andrii Nakryiko [this message]
2019-02-27 23:30 ` [PATCH bpf-next 4/5] samples: bpf: use libbpf where easy Jakub Kicinski
2019-02-28  0:05   ` Andrii Nakryiko
2019-02-28  0:21     ` Jakub Kicinski
2019-02-27 23:30 ` [PATCH bpf-next 5/5] tools: libbpf: make sure readelf shows full names in build checks Jakub Kicinski
2019-02-28  0:11   ` Andrii Nakryiko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAEf4BzZuOeUXKUmMqukQm2M1eTnX2=JwkNyfwF5FvbMEuby9BQ@mail.gmail.com' \
    --to=andrii.nakryiko@gmail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jakub.kicinski@netronome.com \
    --cc=netdev@vger.kernel.org \
    --cc=oss-drivers@netronome.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).