Re: "statsfs" API design

Brian Masney
2019-11-10T10:09:16Z

On Sun, Nov 10, 2019 at 10:14:35AM +0100, Greg KH wrote:
> On Sat, Nov 09, 2019 at 09:44:41PM +0300, Alexey Dobriyan wrote:
> > > statsfs is a proposal for a new Linux kernel synthetic filesystem,
> > > to be mounted in /sys/kernel/stats
> >
> > I think /proc experiment teaches pretty convincingly that dressing
> > things into a filesystem can be done but ultimately is a stupid idea.
> > It adds so much overhead for small-to-medium systems.
> >
> > > The first user of statsfs would be KVM, which is currently exposing
> > > its stats in debugfs
> >
> > > Google has KVM patches to gather statistics in a binary format
> >
> > Which is a right thing to do.
>
> It's always "simpler" to just take binary data and suck it in. That
> works for a year or so until another value needs to be supported. Or
> removed. Or features are backported.
>
> The reason text values in individual files work is they are "self
> describable" and "self discoverable". You "know" what the value is and
> that it is supported because the file is there or not. With binary
> values in a single file you do not know any of that.
>
> So you need some way of describing the data to userspace in order for
> this to work properly over the next 20+ years.
>
> Maybe something like varlink which describes the data coming from the
> kernel in an easy-to-handle format? Or something else, but just using
> blobs does not work over the long-term, sorry.

What about using a text format like YAML? Here's some benefits:

- The fields are self describing based on the key name.
- New fields can be easily added without breaking compatibility.
- Allows for a script to easily parse the contents while keeping
human readability.
- Would work for systems that run busybox as their userspace without
having to install additional tools.
- Allows for a nested data structure.

The downside is that the output would be larger than a binary interface
but it's more maintainable in my opinion.

Brian