Re: [PATCH proxmox-ebpf v5 0/5] add proxmox-ebpf library

[Hannes Laimer <h.laimer@proxmox.com>]

On 2026-11-04 11:30, Fabian Grünbichler wrote:
> On November 3, 2026 10:48 am, Hannes Laimer wrote:
>> On 2026-11-03 10:23, Thomas Lamprecht wrote:
>>> Am 03.11.26 um 09:58 schrieb Hannes Laimer:
>>>> On 2026-11-02 21:19, Thomas Lamprecht wrote:
>>>>> Am 02.11.26 um 16:09 schrieb Hannes Laimer:
>>>>>> The series applies on top of the scaffolding commit of the repo, which
>>>>>> is not on the list since it carries the vendored vmlinux.h at ~167k
>>>>>> lines. It is on my staff repo along with these five commits.
>>>>>
>>>>> So that's basically the reasoning to not put this inside the common
>>>>> proxmox workspace I guess? FWIW; the header is quite nicely tracked
>>>>> in git and as long as we do not have to highly frequently update it,
>>>>> putting this inside proxmox workspace might be a nicer trade-of
>>>>> compared to a dedicated repo.
>>>>>
>>>>
>>>> the reason was mostly because I had this as a binary(kind of like the
>>>> fw) in the beginning, I just didn't really consider moving it there
>>>> since. the only thing is that this is the first using clang in its
>>>> build.rs, so we'd need clang, libbpf-dev and linux-libc-dev as deps for
>>>> the workspace. don't think that should be a problem though
>>>
>>> Not for the workspace, each crate dir has its own packaging, i.e. those
>>> are all different source packages. But we indeed do not have any other
>>> "real" binary package, as in non-librust-source-code one. Can we host
>>
>> it is still no binary though, we still ship just the code, rust+C here,
>> and the build.rs does the compiling on the consumer. what is added is
>> just the dep to clang and the two libs. it wouldn't ship anything binary
> 
> I guess there's a reason why we go with C here? Rust can compile to BPF
> as well after all (newer versions of the toolchain packages ship a
> prebuilt BPF target, and also support build-std now, but that is not yet
> in our builds IIRC).

yes, basically that, but we'd also need aya-ebpf(+the bpf linker),
otherwise we would re-implement bpf_helpers.h in rust.. which i don't
think we want

> 
> I do think (if we stick with C/clang) that we should use a versioned
> clang (e.g., clang-21/clang-22) to avoid surprises.
> 

sure

> FWIW, we already have other crates in our transitive dep tree in the
> proxmox workspace that use clang-sys or cc, like nettle-sys or
> openssl-sys, so I think either proxmox, proxmox-firewall or
> proxmox-ve-rs should be fine.
> 

proxmox-firewall is built mostly around the firewall binary, and this is
really scoped towards just PVEs SDN, proxmox-ve-rs is probably the best
fit here, since proxmox mostly contains non-product-specific code

> pve-network is currently a perl-only, single-source repo so I'd leave
> that out.

thanks for your input! :)