https://bugzilla.redhat.com/show_bug.cgi?id=2260538 Toke Høiland-Jørgensen <thoiland@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |thoiland@xxxxxxxxxx --- Comment #16 from Toke Høiland-Jørgensen <thoiland@xxxxxxxxxx> --- (In reply to Neal Gompa from comment #7) > > /var/lib/kepler/bpfassets/amd64_kepler.bpf.o > > This should probably be installed into "%{_libexecdir}/kepler/bpfassets" > instead. Actually, we've been trying to establish %{_libdir}/bpf/ as the place to put BPF object files, cf: https://src.fedoraproject.org/rpms/xdp-tools/blob/rawhide/f/xdp-tools.spec#_105 However, it looks like the loader code hard-codes the location of the object file: https://github.com/sustainable-computing-io/kepler/blob/main/pkg/bpfassets/attacher/libbpf_attacher.go#L41 This should probably be changed so the Makefile can override it. (In reply to Viktor Malik from comment #15) > From specfile: > > > BuildRequires: [...] libbpf > > How does Kepler load the BPF program? I assume it uses libbpf so libbpf > should be a runtime dependency (i.e. in "Requires"), unless you're linking > against it statically. > > On the contrary, I'd expect libbpf-devel in "BuildRequires". Looking at the top-level Makefile, it does appear that Kepler links statically against libbpf: https://github.com/sustainable-computing-io/kepler/blob/main/Makefile#L51 Not sure if we have a policy for this in Fedora, but at least in RHEL this won't be allowed. So at some point this needs to be changed to link dynamically against the system libbpf. > > New question :) - if this is platform-independent eBPF bytecode, why prefix the name with amd64? For people on other arches this is going to be a source of confusion - looking at my aarch64 laptop and my confusion RN for example ;) > > Agreed with Nathan here. BPF binaries are arch-independent (they are ELFs > with a special "BPF" architecture) so the prefix shouldn't be there. AFAICT from the Kepler sources, it's arch-specific because the build includes different versions of vmlinux.h depending on the defined architecture: https://github.com/sustainable-computing-io/kepler/blob/main/bpfassets/libbpf/src/kepler.bpf.h This should not be necessary for most accesses, CO-RE can be used instead. I am not sure if there are some arch-specific structs that Kepler needs to access, though, and whether CO-RE can handle those. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2260538 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202260538%23c16 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
