Wed, Aug 05, 2020 at 11:33:38AM CEST, yan.y.z...@intel.com wrote:
>On Wed, Aug 05, 2020 at 04:02:48PM +0800, Jason Wang wrote:
>>
>> On 2020/8/5 下午3:56, Jiri Pirko wrote:
>> > Wed, Aug 05, 2020 at 04:41:54AM CEST, jasow...@redhat.com wrote:
>> > > On 2020/8/5 上午10:16, Yan Zhao wrote:
>> > > > On Wed, Aug 05, 2020 at 10:22:15AM +0800, Jason Wang wrote:
>> > > > > On 2020/8/5 上午12:35, Cornelia Huck wrote:
>> > > > > > [sorry about not chiming in earlier]
>> > > > > >
>> > > > > > On Wed, 29 Jul 2020 16:05:03 +0800
>> > > > > > Yan Zhao wrote:
>> > > > > >
>> > > > > > > On Mon, Jul 27, 2020 at 04:23:21PM -0600, Alex Williamson wrote:
>> > > > > > (...)
>> > > > > >
>> > > > > > > > Based on the feedback we've received, the previously proposed
>> > > > > > > > interface
>> > > > > > > > is not viable. I think there's agreement that the user needs
>> > > > > > > > to be
>> > > > > > > > able to parse and interpret the version information. Using
>> > > > > > > > json seems
>> > > > > > > > viable, but I don't know if it's the best option. Is there any
>> > > > > > > > precedent of markup strings returned via sysfs we could follow?
>> > > > > > I don't think encoding complex information in a sysfs file is a
>> > > > > > viable
>> > > > > > approach. Quoting Documentation/filesystems/sysfs.rst:
>> > > > > >
>> > > > > > "Attributes should be ASCII text files, preferably with only one
>> > > > > > value
>> > > > > > per file. It is noted that it may not be efficient to contain only
>> > > > > > one
>> > > > > > value per file, so it is socially acceptable to express an array of
>> > > > > > values of the same type.
>> > > > > > Mixing types, expressing multiple lines of data, and doing fancy
>> > > > > > formatting of data is heavily frowned upon."
>> > > > > >
>> > > > > > Even though this is an older file, I think these restrictions still
>> > > > > > apply.
>> > > > > +1, that's another reason why devlink(netlink) is better.
>> > > > >
>> > > > hi Jason,
>> > > > do you have any materials or sample code about devlink, so we can have
>> > > > a good
>> > > > study of it?
>> > > > I found some kernel docs about it but my preliminary study didn't show
>> > > > me the
>> > > > advantage of devlink.
>> > >
>> > > CC Jiri and Parav for a better answer for this.
>> > >
>> > > My understanding is that the following advantages are obvious (as I
>> > > replied
>> > > in another thread):
>> > >
>> > > - existing users (NIC, crypto, SCSI, ib), mature and stable
>> > > - much better error reporting (ext_ack other than string or errno)
>> > > - namespace aware
>> > > - do not couple with kobject
>> > Jason, what is your use case?
>>
>>
>> I think the use case is to report device compatibility for live migration.
>> Yan proposed a simple sysfs based migration version first, but it looks not
>> sufficient and something based on JSON is discussed.
>>
>> Yan, can you help to summarize the discussion so far for Jiri as a
>> reference?
>>
>yes.
>we are currently defining an device live migration compatibility
>interface in order to let user space like openstack and libvirt knows
>which two devices are live migration compatible.
>currently the devices include mdev (a kernel emulated virtual device)
>and physical devices (e.g. a VF of a PCI SRIOV device).
>
>the attributes we want user space to compare including
>common attribues:
>device_api: vfio-pci, vfio-ccw...
>mdev_type: mdev type of mdev or similar signature for physical device
> It specifies a device's hardware capability. e.g.
> i915-GVTg_V5_4 means it's of 1/4 of a gen9 Intel graphics
> device.
>software_version: device driver's version.
> in .[.bugfix] scheme, where there is no
>
