From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Christoph Heiss <c.heiss@proxmox.com>,
Dominik Csapak <d.csapak@proxmox.com>
Subject: Re: [pve-devel] [RFC PATCH common] SysFSTools: mdev: retrieve Nvidia vGPU description from nvidia-smi
Date: Wed, 30 Oct 2024 13:08:28 +0100 [thread overview]
Message-ID: <8a2eac73-7f86-4715-b479-6215033189c0@proxmox.com> (raw)
In-Reply-To: <20241028113114.550887-1-c.heiss@proxmox.com>
higher level comment, so CCing also Dominik:
Is pve-common, and possibly even SysFSTools the right place for this?
As in from a quick look this has nothing to do with sysfs directly, and
from recent development it seems like placing such things into a more
specific package, and probably also (binary) package might be better.
Don't get me wrong, I'm fine with the code living in pve-common, while
I'm a fan of having more modular packages, at least for bigger projects
like PVE, this does correlates with the amount of git repos I'd like
to manage.
As pve-common, and lots of its perl modules, are pretty overloaded already
I'd like to avoid expanding this further.
In the long term, i.e. not a requirement for this series, I'd like to
have not only the perl module split up (*stares at PVE::Tools*), but also
then leverage that and provide more binary packages so that we can better
reuse specific things without pulling so many dependencies transitively.
We sometimes just copy over common helpers to avoid that, e.g. for some
non-PVE (infra) tooling, so the pain *is* real.
So while you certainly do not need to fix all of that just to get your
changes here in, it would be OTOH great if we could not make this tech
debt worse; so lets create a new package and possibly also finer-grained
modules for this.
The hard thing is to carve out what belongs together, and lets not be
strictly limited by existing module layout, method from those can be
split and merged.
Some rough/unfinished ideas/proposal from top of my head:
- possible package names:
- libpve-device-common (or host-device / hw-device as slight alternations)
- libpve-sysfs-common (if sysfs is really only what this does, which then
should not need any external tools or compiled programs)
- libpve-hw-passthrough-common
- modules: The basename might depend a bit on the package named chosen, could
be e.g. "PVE::Device" or "PVE::SysFS"
- $basename::USB
- $basename::PCI
- $basename::PCI::NVIDIA
In general, it can be also fine to have a very generic (micro) package with
just sysfs helpers, or keep that in existing pve-common, and then depend
on that in a more specific package that provides passthrough related stuff
on top of that, mixing sysfs query/writing with some potential calling of
external tools.
As said, the direction should be that, and great if some parts of pve-common
can be improved "for free" w.r.t. not being huge modules in a huge package,
but there's no need to rework all of pve-common now already just for this.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2024-10-30 12:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-28 11:31 Christoph Heiss
2024-10-30 10:13 ` Dominik Csapak
2024-10-30 11:09 ` Christoph Heiss
2024-10-30 12:08 ` Thomas Lamprecht [this message]
2024-10-30 13:50 ` Christoph Heiss
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=8a2eac73-7f86-4715-b479-6215033189c0@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=c.heiss@proxmox.com \
--cc=d.csapak@proxmox.com \
--cc=pve-devel@lists.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox