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

[Stefan Hanreich <s.hanreich@proxmox.com>]

On 11/4/26 12:27 PM, Hannes Laimer wrote:
> 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
I was also thinking about ve-rs. In short/mid-term I'm not sure if we
shouldn't just move all the firewall related parts from ve-rs to proxmox
or proxmox-firewall completely. That'd leave us with the SDN specific
stuff here and we could potentially turn that into a proxmox-sdn workspace?
But I'm unsure if we want to add further crates there that deal with other,
non-SDN stuff or where those would go then?