lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 30 Dec 2014 10:20:21 +0100 From: Andreas Mohr <andi@...as.de> To: Ethan Zhao <ethan.zhao@...cle.com> Cc: bhelgaas@...gle.com, linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org, ethan.kernel@...il.com, Ethan Zhao <ethan.zhao@...cle.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org> Subject: Re: [PATCH] PCI: export pci device assignment info as read only via sysfs Hi, Ethan Zhao wrote: > This patch exports assignment flag of PCI device via sysfs, so user > space application could know if PCI device was assigned to guest OS > or not via interface as following from viewpoint of host device > management: > > PCI device was assigned to guest OS > $cat /sys/devices/pci0000:00/0000:00:1f.3/assigned > 1 > PCI device isn't assigned to guest OS > $cat /sys/devices/pci0000:00/0000:00:1f.3/assigned > 0 For such a sysfs API (and similar cases in general!), do we actually want this relatively simple interface of "assigned" false/true? Or should it rather be something like an "ownership" attribute which could then indicate interface-fixed(!) string values such as "system"/"vm_guest"/FUTURE_EXTENSION_POSSIBILITY? IOW, "assigned" is quite a bit less flexible (and quite possibly even less usability-suitable from a naming POV - "assigned"...??) but of course simpler (which may or may not pose an advantage from an interface versioning/evolution POV). To further clarify things, this "assigned" interface as-is can merely tell apart the "device is occupied" vs. "device is not occupied" cases yet it could easily provide exact ownership details instead. And I'm also wondering whether or not it's good to have it directly/symmetrically named "assigned" due to it currently(!!) being based internally on an equally-named pci_is_dev_assigned() API. I should probably read up on sysfs item design hints/guidelines which I'd trust to be accurately explained in a Documentation/ file ;) Hmm, seems Documentation/sysfs-rules.txt has only one closing remark which seems relevant: ==== Userspace applications can, however, expect the format and contents of the attribute files to remain consistent in the absence of a version attribute change in the context of a given attribute. ==== This would be fulfilled by both the current and my suggested variant of this interface, AFAICS. Thanks, Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists