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