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

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

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

> 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?

yes, should work fine, just wasn't really aware of this

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