Re: device compatibility interface for live migration with assigned devices

Wed, Aug 05, 2020 at 04:41:54AM CEST, jasowang(a)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 <yan.y.zhao(a)intel.com&gt; 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?

> Thanks > > >> Thanks >> Yan >>