Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> writes: >> May be we should talk about problem statement and goals. >> Do we actually need metadata per program or metadata per single .o >> or metadata per final .o with multiple .o linked together? >> What is this metadata? > > Yep, that's a very valid question. I've also CC'ed Andrey. For the libxdp use case, I need metadata per program. But I'm already sticking that in a single section and disambiguating by struct name (just prefixing the function name with a _ ), so I think it's fine to have this kind of "concatenated metadata" per elf file and parse out the per-program information from that. This is similar to the BTF-encoded "metadata" we can do today. >> If it's just unreferenced by program read only data then no special names or >> prefixes are needed. We can introduce BPF_PROG_BIND_MAP to bind any map to any >> program and it would be up to tooling to decide the meaning of the data in the >> map. For example, bpftool can choose to print all variables from all read only >> maps that match "bpf_metadata_" prefix, but it will be bpftool convention only >> and not hard coded in libbpf. > > Agree as well. It feels a bit odd for libbpf to handle ".metadata" > specially, given libbpf itself doesn't care about its contents at all. > > So thanks for bringing this up, I think this is an important > discussion to have. I'm fine with having this be part of .rodata. One drawback, though, is that if any metadata is defined, it becomes a bit more complicated to use bpf_map__set_initial_value() because that now also has to include the metadata. Any way we can improve upon that? -Toke
