On 10/12/2016 7:22 AM, Tian, Kevin wrote: >> From: Kirti Wankhede [mailto:kwankhede@xxxxxxxxxx] >> 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: > We had internal discussions about this within NVIDIA and found that 'name' might not be unique where as 'type_id' would be unique. I'm refering to Neo's mail after that, where Neo do pointed that out. https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg07714.html Thanks, Kirti -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
