On Tue, 26 May 2020 13:03:10 +0200 Emanuele Giuseppe Esposito wrote: > There is currently no common way for Linux kernel subsystems to expose > statistics to userspace shared throughout the Linux kernel; subsystems have > to take care of gathering and displaying statistics by themselves, for > example in the form of files in debugfs. For example KVM has its own code > section that takes care of this in virt/kvm/kvm_main.c, where it sets up > debugfs handlers for displaying values and aggregating them from various > subfolders to obtain information about the system state (i.e. displaying > the total number of exits, calculated by summing all exits of all cpus of > all running virtual machines). > > Allowing each section of the kernel to do so has two disadvantages. First, > it will introduce redundant code. Second, debugfs is anyway not the right > place for statistics (for example it is affected by lockdown) > > In this patch series I introduce statsfs, a synthetic ram-based virtual > filesystem that takes care of gathering and displaying statistics for the > Linux kernel subsystems. > > The file system is mounted on /sys/kernel/stats and would be already used > by kvm. Statsfs was initially introduced by Paolo Bonzini [1]. What's the direct motivation for this work? Moving KVM stats out of debugfs? In my experience stats belong in the API used for creating/enumerating objects, statsfs sounds like going in the exact opposite direction - creating a parallel structure / hierarchy for exposing stats. I know nothing about KVM but are you sure all the info that has to be exposed will be stats? In case of networking we have the basic stats in sysfs, under the netdevice's kobject. But since we're not using sysfs much any more for config, new stats are added in netlink APIs. Again - same APIs used for enumeration and config.
