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? > >Thanks > > >> >> Thanks >> Yan >> >
