I hope the change owners are working to ensure this works on Fedora RISC-V too...

+1

Thanks neal, we'll sure aim to get this to every possible architecture. We're so far coordinating with Fabio Valentini on the builds (and on the needed rust dependencies to be added)

+1

+1

+1

+1

Procedural -1.

This is seems to be a nice tool, making some uses of bpf much easier.

Nevertheless, if I understand the Change Page and the discussion correctly, the title and the Summary are very misleading.

Bpfman as default eBPF manager

it becomes the de-facto and easy way to load eBPF programs.

but

For now we’ll just go ahead, package bpfman as you suggest and not install it as default.

I was trying to understand what the planned scope really is, and this discussion happened independently, so clearly I'm not the only one confused by this.

There are other uses of BPF. In particular, systemd has support for bpf internally, and it is extensively used to implement unit sandboxes (per-unit firewalls, device access limitations) and also allows loading arbitrary user programs via BPFProgram=. Thus, even if bpfman is installed by default, I don't think it'd be true to say that its the "de-facto way to load BPF programs".

I think we should wait with the approval until the title and Summary are clarified. (Scope actually only mentions packaging, but not every reader gets that far down in the page.)

Also, gRPC is a bit surprising. For communication between services, D-Bus would be a more natural choice. Maybe this is all OK, but I'd like to see more discussion before we start using a new protocol in the base layer of the system.

Hi Zbginew,

Thanks for asking for clarification over here.

Nevertheless, if I understand the Change Page and the discussion correctly, the title and the Summary are very misleading.

I'm totally fine about changing the Summary to something along the lines of "Adding bpfman to Fedora 40" in this case.

I think we should wait with the approval until the title and Summary are clarified. (Scope actually only mentions packaging, but not every reader gets that far down in the page.)

Basically, out first goal is for this to be available in Fedora 40 despite any other tooling. Hope this clarifies things now.

Even if we aim for this to become a default tool for managing bpf programs in Fedora and to become a tool for every user to be able to load bpf programs in an easier way we can leave that out of the scope of this change.

Regarding gRPC and d-bus, that's something we may implement later but for now I hope that this section here https://bpfman.io/main/getting-started/example-bpf/#notes makes things clearer.

Thanks!

Hi FESCo members,

Is this change proposal going to be discussed in the next meeting? Or is @dmellado 's clarification above suitable to continue the vote?

Thanks!
Aoife

Unless @zbyszek changes his vote, this remains targeted at the next meeting.

I'm totally fine about changing the Summary to something along the lines of "Adding bpfman to Fedora 40" in this case.

That'd be great. Please make the change in the wiki.

Hi @zbyszek . Thanks for the clarification over there and for having a chat with me at the FOSDEM conference. I've just updated the wiki page with the changes we spoke about and mention here, so I do hope that you're now ok with the change. Thanks!

Thank you.

+1

It's exactly two weeks since the start of the voting, so let's mark this as:
APPROVED (+6, 0, 0)