Erik Skultety <eskultet@redhat.com> 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