Re: [PATCH bpf-next v4 5/8] libbpf: Support opening bpf objects of either endianness

[Tony Ambardar <tony.ambardar@gmail.com>]

On Fri, Aug 30, 2024 at 06:26:10PM -0700, Eduard Zingerman wrote:
> On Fri, 2024-08-30 at 14:25 -0700, Andrii Nakryiko wrote:
> 
> [...]
> 
> > >         err = bpf_object__elf_init(obj);
> > > -       err = err ? : bpf_object__check_endianness(obj);
> > >         err = err ? : bpf_object__elf_collect(obj);
> > >         err = err ? : bpf_object__collect_externs(obj);
> > >         err = err ? : bpf_object_fixup_btf(obj);
> > > @@ -8500,6 +8529,10 @@ static int bpf_object_load(struct bpf_object *obj, int extra_log_level, const ch
> > > 
> > >         if (obj->gen_loader)
> > >                 bpf_gen__init(obj->gen_loader, extra_log_level, obj->nr_programs, obj->nr_maps);
> > 
> > nit: add {} around if, both sides should either have or not have {}
> > 
> > > +       else if (!is_native_endianness(obj)) {
> > > +               pr_warn("object '%s' is not native endianness\n", obj->name);
> > 
> > "object '%s': load is not supported in non-native endianness\n"
> > 
> > 
> > > +               return libbpf_err(-LIBBPF_ERRNO__ENDIAN);
> > > +       }
> 
> Silly question:
>   why load is allowed to proceed for non-native endianness when obj->gen_loader is set?
> 

Not silly, had similar questions. Having obj->gen_loader set means "light
skeleton" is being generated, where it tries to eliminate dependency on
libbpf by skeleton code. In this mode, the code doesn't load anything but
instead tracks "what would libbpf do" so it can later write a pure BPF
loader program. Alexei will correct me or elaborate as needed I hope.

Unconditionally blocking on non-native endianness would break light skel.