On Thu, Oct 21, 2021 at 8:59 AM Lorenz Bauer <lmb@xxxxxxxxxxxxxx> wrote:
>
> On Wed, 20 Oct 2021 at 18:15, Alexei Starovoitov
> <alexei.starovoitov@xxxxxxxxx> wrote:
> >
> > > + struct { /* used by BPF_PROG_GET_FD_BY_ID command */
> > > + __u32 id;
> > > + } prog_get_fd_by_id;
> > > +
> > > + struct { /* used by BPF_MAP_GET_FD_BY_ID command */
> > > + __u32 id;
> > > + __u32 ingnored;
> > > + __u32 open_flags;
> > > + } map_get_fd_by_id;
> > > +
>
> > > + struct { /* used by BPF_PROG_GET_NEXT_ID command */
> > > + __u32 start_id;
> > > + __u32 next_id;
> > > + } prog_get_next_id;
> > > +
>
> > This one looks like churn though.
>
> Yes, but it's still better than what we have now. There are three
> distinct syscall signatures that a user needs to understand, which is
> impossible right now without looking at the source. map_get_fd_by_id
> is arguably dodgy with one field completely ignored. Having one struct
> for each bpf_cmd makes code generation easier as well.
>
> I could reduce this to just the three different variants, it opens us
> up to another map_get_fd_by_id.
yes, but even with all of them there is still a risk of repeating
map_get_fd_by_id mistake.
To make progress maybe let's land the bits that we agree on
and keep brainstorming on the rest?
Or that's too little to be useful for automatic golang conversion?
If the whole thing is needed then golang converting script
should probably be part of the series otherwise things will bit rot.
