From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id C840C1FF0AA for ; Tue, 03 Nov 2026 10:48:50 +0100 (CET) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 2FD9F2181B; Tue, 03 Nov 2026 10:48:47 +0100 (CET) Message-ID: <6a66dba5-d94f-4159-a761-9a66d17cd567@proxmox.com> Date: Tue, 3 Nov 2026 10:48:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH proxmox-ebpf v5 0/5] add proxmox-ebpf library To: Thomas Lamprecht , pve-devel@lists.proxmox.com References: <20261102150047.1584789-1-h.laimer@proxmox.com> <7826f3d1-4f90-411c-ba45-8bff7ef8a214@proxmox.com> From: Hannes Laimer Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1793699304425 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.337 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: GBNZYVKM7A64XFH24WLKO7OF5JK45GJQ X-Message-ID-Hash: GBNZYVKM7A64XFH24WLKO7OF5JK45GJQ X-MailFrom: h.laimer@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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! :) >