[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191110091435.GC1435668@kroah.com>
Date: Sun, 10 Nov 2019 10:14:35 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Alexey Dobriyan <adobriyan@...il.com>
Cc: pbonzini@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: "statsfs" API design
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.
greg k-h
Powered by blists - more mailing lists