Open Stack

On 2020/8/18 下午5:16, Daniel P. Berrangé wrote:
> Your mail came through as HTML-only so all the quoting and attribution
> is mangled / lost now :-(


My bad, sorry.


>
> On Tue, Aug 18, 2020 at 05:01:51PM +0800, Jason Wang wrote:
>>     On 2020/8/18 下午4:55, Daniel P. Berrangé wrote:
>>
>>   On Tue, Aug 18, 2020 at 11:24:30AM +0800, Jason Wang wrote:
>>
>>   On 2020/8/14 下午1:16, Yan Zhao wrote:
>>
>>   On Thu, Aug 13, 2020 at 12:24:50PM +0800, Jason Wang wrote:
>>
>>   On 2020/8/10 下午3:46, Yan Zhao wrote:
>>   we actually can also retrieve the same information through sysfs, .e.g
>>
>>   |- [path to device]
>>      |--- migration
>>      |     |--- self
>>      |     |   |---device_api
>>      |    |   |---mdev_type
>>      |    |   |---software_version
>>      |    |   |---device_id
>>      |    |   |---aggregator
>>      |     |--- compatible
>>      |     |   |---device_api
>>      |    |   |---mdev_type
>>      |    |   |---software_version
>>      |    |   |---device_id
>>      |    |   |---aggregator
>>
>>
>>   Yes but:
>>
>>   - You need one file per attribute (one syscall for one attribute)
>>   - Attribute is coupled with kobject
>>
>>   All of above seems unnecessary.
>>
>>   Another point, as we discussed in another thread, it's really hard to make
>>   sure the above API work for all types of devices and frameworks. So having a
>>   vendor specific API looks much better.
>>
>>   From the POV of userspace mgmt apps doing device compat checking / migration,
>>   we certainly do NOT want to use different vendor specific APIs. We want to
>>   have an API that can be used / controlled in a standard manner across vendors.
>>
>>     Yes, but it could be hard. E.g vDPA will chose to use devlink (there's a
>>     long debate on sysfs vs devlink). So if we go with sysfs, at least two
>>     APIs needs to be supported ...
> NB, I was not questioning devlink vs sysfs directly. If devlink is related
> to netlink, I can't say I'm enthusiastic as IMKE sysfs is easier to deal
> with. I don't know enough about devlink to have much of an opinion though.
> The key point was that I don't want the userspace APIs we need to deal with
> to be vendor specific.
>
> What I care about is that we have a *standard* userspace API for performing
> device compatibility checking / state migration, for use by QEMU/libvirt/
> OpenStack, such that we can write code without countless vendor specific
> code paths.
>
> If there is vendor specific stuff on the side, that's fine as we can ignore
> that, but the core functionality for device compat / migration needs to be
> standardized.


Ok, I agree with you.

Thanks


>
> Regards,
> Daniel