
From: Tian, Kevin Sent: Thursday, September 22, 2016 10:33 AM
Another example is class-specific attributes such as 'resolution', etc. which you listed under 'display class'. All those attributes should be moved to mdev directory. Only class ID is required under each type.
Can you elaborate on what you're proposing here? If we don't have attributes like 'resolution' under the type-id then we can't describe to the user the features of the mdev before we create it. I don't think anybody wants a 'create it and find out' type of interface. Thanks,
I think such way would be racy. What about two clients creating mdev devices simultaneously? How to guarantee their configuration of class specific attributes not mutual-impacted since before creation any such configuration would be global under that type?
My feeling is that we'd better keep create simple - just write a UUID to "type-id/create". Any class-specific attribute, if we really want to support, should be able to be individually configured with required resource allocated incrementally on top of basic resources allocated at create stage. Then libvirt can set those attributes between create and open a mdev device. If this direction is accepted, then naturally such attributes should be put under mdev directory. Possibly we don't need a class description under type-id. libvirt just checks directly whether any known class represented in each mdev directory (vendor driver will expose it on demand), and then operate attributes under that class.
Have a better understanding of your concern now. User needs to know and set a list of attributes before requesting to create a new mdev device. From this angle all attributes should be enumerated per type-id. But as I explained above, writing multiple sysfs nodes to create a mdev device is racy. We either need a way to guarantee transactional operations on those nodes, or having type-id directory to only expose supported attributes while programming those attributes has to be through per-mdev directory after mdev device is created... Thanks Kevin