On 21/01/20 16:38, Alexander Graf wrote: >>>> ONE_REG would force us to define constants for each counter, and would >>>> make it hard to retire them. I don't like this. >>> >>> Why does it make it hard to retire them? We would just return -EINVAL >>> on retrieval, like we do for any other non-supported ONE_REG. >>> >>> It's the same as a file not existing in debugfs/statfs. Or an entry >>> in the array of this patch to disappear. The devil is in the details. For example, would you retire uapi/ constants and cause programs to fail compilation? Or do you keep the obsolete constants forever? Also, fixing the mapping from ONE_REG number to stat would mean a switch statement (or loop of some kind---a switch statement is basically an unrolled binary search) to access the stats. Instead returning the id in KVM_GET_SUPPORTED_DEBUGFS_STAT would simplify returning the stats to a simple copy_to_user. Of course, some of the complexity would be punted to userspace. But userspace is much closer to the humans that ultimately look at the stats, so the question is: does userspace really care about knowing which stat is which, or do they just care about having a name that will ultimately be consumed by humans down the pipe? If the latter (which is also my gut feeling), that is also a point against ONE_REG. > It's not a problem of exposing the type information - we have that today > by implicitly saying "every counter is 64bit". > > The thing I'm worried about is that we keep inventing these special > purpose interfaces that really do nothing but transfer numbers in one > way or another. ONE_REG's purpose was to unify them. Debug counters > really are the same story. See above: I am not sure they are the same story because their consumers might be very different from registers. Registers are generally consumed by programs (to migrate VMs, for example) and only occasionally by humans, while stats are meant to be consumed by humans. We may disagree on whether this justifies a completely different API... Paolo
