On Wed, 27 May 2020 08:27:36 -0600 David Ahern <dsah...@gmail.com> wrote:
> On 5/27/20 4:26 AM, Jesper Dangaard Brouer wrote: > > IMHO we really need to leverage BTF here, as I'm sure we need to do more > > extensions, and this size matching will get more and more unmaintainable. > > > > With BTF in place, dumping the map via bpftool, will also make the > > fields "self-documenting". > > furthermore, the kernel is changing the value - an fd is passed in and > an id is returned. I do not see how any of this fits into BTF. It can, as BTF actually support union's (I just tested that). For the sake of end-users understanding this, I do wonder if it is better to define the struct without the union, and have longer names that will be part of BTF description, e.g (dumped via bpftool): struct dev_map_ext_val { u32 ifindex; int bpf_prog_fd_write; u32 bpf_prog_id_read; }; But a union would also work (also tested via BPF loading and BTF dumpinmg): struct dev_map_ext_val { u32 ifindex; union { int bpf_prog_fd_write; u32 bpf_prog_id_read; }; }; -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer