Re: [Qemu-devel] [PATCH v8 4/6] docs: Add Documentation for Mediated devices

[Tian, Kevin]

> From: Kirti Wankhede [mailto:address@hidden
> Sent: Wednesday, October 12, 2016 4:45 AM
> >> +* mdev_supported_types:
> >> +    List of current supported mediated device types and its details are 
> >> added
> >> +in this directory in following format:
> >> +
> >> +|- <parent phy device>
> >> +|--- Vendor-specific-attributes [optional]
> >> +|--- mdev_supported_types
> >> +|     |--- <type id>
> >> +|     |   |--- create
> >> +|     |   |--- name
> >> +|     |   |--- available_instances
> >> +|     |   |--- description /class
> >> +|     |   |--- [devices]
> >> +|     |--- <type id>
> >> +|     |   |--- create
> >> +|     |   |--- name
> >> +|     |   |--- available_instances
> >> +|     |   |--- description /class
> >> +|     |   |--- [devices]
> >> +|     |--- <type id>
> >> +|          |--- create
> >> +|          |--- name
> >> +|          |--- available_instances
> >> +|          |--- description /class
> >> +|          |--- [devices]
> >> +
> >> +[TBD : description or class is yet to be decided. This will change.]
> >
> > I thought that in previous discussions we had agreed to drop
> > the <type id> concept and use the name as the unique identifier.
> > When reporting these types in libvirt we won't want to report
> > the type id values - we'll want the name strings to be unique.
> >
> 
> The 'name' might not be unique but type_id will be. For example that Neo
> pointed out in earlier discussion, virtual devices can come from two
> different physical devices, end user would be presented with what they
> had selected but there will be internal implementation differences. In
> that case 'type_id' will be unique.
> 

Hi, Kirti, my understanding is that Neo agreed to use an unique type
string (if you still called it <type id>), and then no need of additional
'name' field which can be put inside 'description' field. See below quote:

--<from Alex>--
> I think your discovery only means that for your vendor driver, the name
> will be "11" (as a string).  Perhaps you'd like some sort of vendor
> provided description within each type, but I am not in favor of having
> an arbitrary integer value imply something specific within the sysfs
> interface.  IOW, the NVIDIA vendor driver should be able to create:
> 
> 11
> ├── create
> ├── description
> ├── etc
> └── resolution
> 
> While Intel might create:
> 
> Skylake-vGPU
> ├── create
> ├── description
> ├── etc
> └── resolution
> 
> Maybe "description" is optional for vendors that use useful names?
> Thanks,

--<From Neo>--
> I think we should be able to have a unique vendor type string instead of an
> arbitrary integer value there as long as we are allowed to have a description
> field that can be used to show to the end user as "name / label". 

Thanks
Kevin