Open Stack

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 at intel.com> 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

Thanks


>
> Thanks
> Yan
>