Re: [RFC v3] VFIO Migration

[Cornelia Huck]

On Wed, 11 Nov 2020 15:10:14 +0000
Stefan Hajnoczi <stefanha@redhat.com> wrote:

> On Tue, Nov 10, 2020 at 01:14:04PM -0700, Alex Williamson wrote:
> > On Tue, 10 Nov 2020 09:53:49 +0000
> > Stefan Hajnoczi <stefanha@redhat.com> wrote:
> > Documentation/filesystems/sysfs.rst:
> > ---
> > Attributes
> > ~~~~~~~~~~
> > 
> > Attributes can be exported for kobjects in the form of regular files in
> > the filesystem. Sysfs forwards file I/O operations to methods defined
> > for the attributes, providing a means to read and write kernel
> > attributes.
> > 
> > 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. Doing these things may get
> > you publicly humiliated and your code rewritten without notice.
> > ---
> > 
> > We'd either need to address your TODO and create a hierarchical
> > representation or find another means to exchange this format.  
> 
> Okay, thanks for pointing this out. If the limitations on sysfs
> directory structure are really what I think they are, then we can work
> around the lack of sub-directories by flattening the hierarchical
> information in an attribute name prefix, but it's ugly:
> 
>   <parent-device>/<mdev_supported_types>/<type-id>/
>     migration_param_FOO_off_value
>     migration_param_FOO_init_value
>     migration_param_FOO_description
>     migration_param_FOO_type
> 
> It makes enumerating migration parameters more awkward for userspace
> because they need to skip many of the files when scanning for parameter
> names.
> 
> Or we could create a kobject for each migration parameter, but that
> seems wrong too.

Hm, ISTR that you can do something with ksets.

> 
> Or we could investigate other file systems like configfs. Maybe this is
> why tracefs and other specific file systems exist - sysfs is too
> limited?

If you want to express complex data, sysfs is quickly hitting its
limits. The benefits of using sysfs are basically that sysfs is always
present (and therefore readily consumed by existing tooling), and that
you have device properties properly grouped with the device.