On 2020/8/5 下午3:56, Jiri Pirko wrote:
Wed, Aug 05, 2020 at 04:41:54AM CEST, jasowang@xxxxxxxxxx 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@xxxxxxxxx> 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?
Thanks
Thanks
Thanks
Yan
