On 1/20/26 4:00 PM, Thomas Lamprecht wrote:
Am 20.01.26 um 14:12 schrieb Christoph Heiss:
pci_dev_physfn_id() is used to obtain the parent device of a virtual
function, i.e. the physical function.
Needed for retrieving information about Nvidia vGPU devices via
proxmox-ve-vfio, as libnvidia-ml functions only work with physical
functions.
Signed-off-by: Christoph Heiss <[email protected]>
---
src/PVE/SysFSTools.pm | 45 ++++++++++++++++++++++++++++++-------------
1 file changed, 32 insertions(+), 13 deletions(-)
diff --git a/src/PVE/SysFSTools.pm b/src/PVE/SysFSTools.pm
index a00fbcb..89e57b9 100644
--- a/src/PVE/SysFSTools.pm
+++ b/src/PVE/SysFSTools.pm
@@ -4,8 +4,10 @@ use strict;
use warnings;
use IO::File;
+use File::Basename;
use PVE::Tools qw(file_read_firstline dir_glob_foreach);
+use PVE::RS::VFIO::Nvidia;
we do not depend on libpve-rs-perl in libpve-common-perl, and if easily possible
I'd strongly favor keeping it that way, bootstrapping and handling bigger
package
bumps with newer versioned dependencies or break/depends bumps is already quite
a bit of work as is, such stuff does not make it easier, especially if adding
a new dependencies is not recorded in d/control's packaging definition.
Can this move to some non-leaf package instead? Where are the users of this,
only
qemu-server or other too (pve-manager?)?
hmm.. as far as i can see it, we need to use that module in sysfstools
where we get info about mdevs. This is used in qemu-server
and (currently) pve-manager
If we don't want to have that dep here, we have IMO the following
possiblities:
* split the relevant part out (e.g. into qemu-server, still reachable
from pve-manager).
* move the whole of sysfstools somewhere else
this is needed in guest-common, pve-manager and qemu-server,
so imho guest-common would be the next best place?
though we could also create a seperate package for that too.
Note that pve-storage still includes PVE::SysFSTools, but does not
actually need it anymore, so we should remove it there anyway
Advantage of the second method (though more work) would be to make
pve-common smaller.
We could also think about producing more than one debian package from
pve-common, similar to how we do it with the 'proxmox' rust crate,
not sure how practical that is though.
In summary I think simply moving the mdev/vgpu stuff to qemu-server
makes the most sense for now.
_______________________________________________
pve-devel mailing list
[email protected]
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
