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

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

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
this in proxmox-firewall or maybe even better pve-network as its own
source package there? Else fine to have its own repo I guess, it's a bit
a matter of taste (I do not want a single mono repo, but also not
spreading stuff over to man single one, a bit grouped by topic would be
nice).

Cc'in Fabian and Stefan/Gabriel for packaging and SDN preference here.

>> Oh, and why can't we depend on a proxmox-headers package on build?
>> Like on proxmox-headers-7.0.14-28-pve? that would allow full control
>> without checking the headers file in. Or can't that work or is that
>> not a good fit
> 
> we don't really use kernel internal stuff, and we probably also won't(or
> should not) in the future. so the huge vmlinux.h can actually go, but we
> also don't need proxmox-headers, this is userspace, we shouldn't need
> version specific things

user space can also need (newer) changes I guess. For user space we
got proxmox-kernel-libc-dev - is that enough then?

> 
> ill prepare a v6 moving it into the proxmox workspace.
> thanks for taking a look! :)