Erik Skultety <eskultet@xxxxxxxxxx> writes: > On Tue, Nov 19, 2019 at 05:38:54PM +0100, Milan Zamazal wrote: >> Hi, when retrieving an mdev device info using `virsh nodedev-dumpxml' or >> the libvirt API, something like the following is returned: > >> >> <capability type='mdev_types'> >> <type id='nvidia-210'> >> <name>GRID M60-2B4</name> >> <deviceAPI>vfio-pci</deviceAPI> >> <availableInstances>4</availableInstances> >> </type> >> ... >> </capability> >> >> Besides device_api, available_instances and (optional) `name', >> `description' of the given mdev type may be optionally provided in >> /sys/.../mdev_supported_types/... for each of the available mdev types. >> I can see in the sources that libvirt doesn't try to retrieve it -- is >> it intentionally or is it just an omission? If the latter, could it be >> added, please? It looks like a useful piece of information for the user >> to get an idea what the given mdev type means. > > The reasoning we had about not including the "description" attribute when we > introduced mdevs to libvirt's nodedev driver was that there was no way for > NVIDIA and Intel to agree on the values to be exposed by the attribute - > especially the data NVIDIA puts in there (like you already said) is useful, but > there was also no agreement on extracting the data into a different attribute > (a set of attributes) and make them structured within the XML. > > Which brings me to the actual content of the "description" attribute, it > contains unstructured free-form text and we didn't want to expose that kind of > thing in the XML even though it just so happens that NVIDIA put some > interesting data in it - since the attribute is optional and free-form, one > day, you find the useful data you're interested in now, but tomorrow that may > not be the case anymore and can easily change. I've got no problem with the > idea of exposing some kind of description as part of the XML per se, the > problem I see is that someone will try and start parsing the description field > because of the potentially useful data and if it changes and I'm afraid > complaints will head our way even though we cannot guarantee anything wrt to > that specific field (I'm still open to a discussion though). I agree that it would not be a good idea to rely on the content of the description data or trying to parse it. But if we can accept the description is basically a free-form, less or more informative, text then it is still useful for some purposes. I think your worries about the users relying on the content of the "data" can be handled in documentation, by clearly stating the item may contain anything, which may change any time. Our use case in oVirt is to display some accompanied information when a user selects one of the many mdev types in the UI. If we provided description (as a normal text) next to each of the mdev types, it would be definitely helpful and a significant improvement over just providing the cryptic mdev type numbers + available instances. Currently, we have no better choice than to read `description' files from /sys, which makes little sense when all the other info is already available from libvirt. This is why I think having <description> element with a text content copied 1:1 from `description' file would be useful. Thanks, Milan _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
