From: Christoph Heiss <c.heiss@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [RFC PATCH common] SysFSTools: mdev: retrieve Nvidia vGPU description from nvidia-smi
Date: Wed, 30 Oct 2024 14:50:40 +0100 [thread overview]
Message-ID: <jefk43ia3y7gwoi4ltyq4kcjil2mbdztazto6wqmfl5yf7had6@waxw3hyxtcms> (raw)
In-Reply-To: <8a2eac73-7f86-4715-b479-6215033189c0@proxmox.com>
Thanks for chiming in!
On Wed, Oct 30, 2024 at 01:08:28PM GMT, Thomas Lamprecht wrote:
> higher level comment, so CCing also Dominik:
>
> Is pve-common, and possibly even SysFSTools the right place for this?
To be honest, that was kinda my thought to when I started implementing
this, but didn't know quite where to put it otherwise - other than a
completely new package and whether that is worth the additional effort.
So no, not really.
> [..]
> from recent development it seems like placing such things into a more
> specific package, and probably also (binary) package might be better.
>
> 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.
If that's the way we want to go tho - I'd be happy to put something
concrete together to get started. This change is be a good starting
point for all of this anyway, I think.
And if we split it out anyway, I would really go the way of directly
using libnvml to retrieve all the information. It is not that much more
effort overall and since it being a binary package is fine too, seems
fitting.
>
> 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-host-device(-common)` sounds pretty good IMO; in that it is
quite distinctive about what devices the package actually works with.
`device` alone would be a bit ambiguous, in my mind.
In the long-term, I guess the mdev-related stuff could be moved there
too, being quite a good fit for that too.
> - 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
.. and splitting up such things into vendor specific modules further
down is a good idea too. Keeps things together that should be.
>
> 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
prev parent reply other threads:[~2024-10-30 13:51 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
2024-10-30 13:50 ` Christoph Heiss [this message]
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=jefk43ia3y7gwoi4ltyq4kcjil2mbdztazto6wqmfl5yf7had6@waxw3hyxtcms \
--to=c.heiss@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox