all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Stefan Hanreich <s.hanreich@proxmox.com>
To: "Thomas Lamprecht" <t.lamprecht@proxmox.com>,
	"Hannes Laimer" <h.laimer@proxmox.com>,
	"Fabian Grünbichler" <f.gruenbichler@proxmox.com>,
	pve-devel@lists.proxmox.com
Subject: Re: [PATCH proxmox-ebpf v5 0/5] add proxmox-ebpf library
Date: Wed, 4 Nov 2026 13:36:53 +0100	[thread overview]
Message-ID: <abb7a5c4-83d2-4ba0-bf33-0233cea8a774@proxmox.com> (raw)
In-Reply-To: <58c3bc0d-81bb-4cf7-8a6f-c7b70d2ffe63@proxmox.com>


On 11/4/26 12:50 PM, Thomas Lamprecht wrote:
> Am 04.11.26 um 12:34 schrieb Stefan Hanreich:
>>> 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
> 
> In the mid/long-term proxmox-firewall should provide basic firewalling for
> all our products, inclusive basic shared api/ui integrations. How exactly
> that's structured doesn't have to be defined now, but I'd not see the whole
> firewall area as PVE-only, most of its (more complex) use case might be only
> sensible for PVE, but the basics should be shared.

Agree, that's part of the reason why I wanted to move everything into the
firewall crate at least.
 
>> 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?
> 
> proxmox workspace is fine for this here, and if not really PVE specific (on
> initial introduction and somewhat foreseeable future) I'd also favor that
> for new lib crates in general.
> 
> SDN can be somewhat carved out and could be its own repo with a bunch of
> crates if desired and I have nothing against that if you, Gabriel, Hannes,
> ... see a strong benefit in it. In the end it still needs to produce the
> librust- packaged source code crates and also those that allow PVE, PDM,
> ...? usage and integration nicely, so it doesn't change much - which OTOH
> is also a point for just doing it in proxmox and save a separate repo. We
> can also add a sdn/ folder there to bundle the crates and keep it more
> organized FWIW.

Yeah, moving to to proxmox is fine by me - not sure if we even need a
separate subfolder. That'd then eliminate proxmox-ve-rs completely. It'd
also make building / maintaining the whole stack easier afaict?




  reply	other threads:[~2026-11-04 12:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-02 15:00 [PATCH proxmox-ebpf v5 0/5] add proxmox-ebpf library Hannes Laimer
2026-11-02 15:00 ` [PATCH proxmox-ebpf v5 1/5] tc: add the link plumbing Hannes Laimer
2026-11-02 15:00 ` [PATCH proxmox-ebpf v5 2/5] subsystem: add the shared tc program handling Hannes Laimer
2026-11-02 15:00 ` [PATCH proxmox-ebpf v5 3/5] subsystem: place the links of different subsystems in a fixed order Hannes Laimer
2026-11-02 15:00 ` [PATCH proxmox-ebpf v5 4/5] tests: add a native harness for the BPF C programs Hannes Laimer
2026-11-02 15:00 ` [PATCH proxmox-ebpf v5 5/5] debian: package the crate as a Rust library Hannes Laimer
2026-11-02 20:19 ` [PATCH proxmox-ebpf v5 0/5] add proxmox-ebpf library Thomas Lamprecht
2026-11-03  8:58   ` Hannes Laimer
2026-11-03  9:23     ` Thomas Lamprecht
2026-11-03  9:48       ` Hannes Laimer
2026-11-04 10:30         ` Fabian Grünbichler
2026-11-04 11:27           ` Hannes Laimer
2026-11-04 11:34             ` Stefan Hanreich
2026-11-04 11:50               ` Thomas Lamprecht
2026-11-04 12:36                 ` Stefan Hanreich [this message]
2026-11-04 13:50 ` superseded: " Hannes Laimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=abb7a5c4-83d2-4ba0-bf33-0233cea8a774@proxmox.com \
    --to=s.hanreich@proxmox.com \
    --cc=f.gruenbichler@proxmox.com \
    --cc=h.laimer@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=t.lamprecht@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal