On Tue, Feb 28, 2023 at 08:01:51PM +0100, Toke Høiland-Jørgensen wrote: > Daniel P. Berrangé <berra...@redhat.com> writes: > > Just to interject a note on this here: the skeleton code is mostly a > convenience feature used to embed BPF programs into the calling binary. > It is perfectly possible to just have the BPF object file itself reside > directly in the file system and just use the regular libbpf APIs to load > it. Some things get a bit more cumbersome (mostly setting values of > global variables, if the BPF program uses those). > > So the JSON example above could just be a regular compiled-from-clang > BPF object file, and the management program can load that, inspect its > contents using the libbpf APIs and pass the file descriptors on to Qemu. > It's even possible to embed version information into this so that Qemu > can check if it understands the format and bail out if it doesn't - just > stick a version field in the configuration map as the first entry :)
If all you have is the BPF object file is it possible to interrogate it to get a list of all the maps, and get FDs associated for them ? I had a look at the libbpf API and wasn't sure about that, it seemed like you had to know the required maps upfront ? If it is possible to auto-discover everything you need, soley from the BPF object file as input, then just dealing with that in isolation would feel simpler. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
