Re: [PATCH v2] drivers/virt/vSMP: new driver

From: Greg Kroah-Hartman
Date: Thu Aug 25 2022 - 08:19:35 EST


On Thu, Aug 25, 2022 at 12:02:12PM +0000, Czerwacki, Eial wrote:
> >On Thu, Aug 25, 2022 at 10:41:28AM +0000, Czerwacki, Eial wrote:
> >> >On Thu, Aug 25, 2022 at 10:16:59AM +0000, Czerwacki, Eial wrote:
> >> >> >> >And why is your version file a binary file? It should just be a small
> >> >> >> >text string, right?
> >> >> >> not so small, it can reach up to 512kb.
> >> >> >
> >> >> >That was not obvious at all. Please document this.
> >> >> where should the document be?
> >> >> in the code as a comment or in another file?
> >> >
> >> >In the Documentation/ABI/ file that describes this file.
> >> ok, will place it there
> >>
> >> >
> >> >> >And how in the world is a "version" that big? What exactly does this
> >> >> >contain?
> >> >> it 's size depends on the number of resources it uses.
> >> >> here is an example:
> >> >> :~> cat /sys/hypervisor/vsmp/version
> >> >> SAP vSMP Foundation: 10.6.2862.0 (Aug 22 2022 15:21:02)
> >> >> System configuration:
> >> >> Boards: 2
> >> >> 1 x Proc. + I/O + Memory
> >> >> 1 x NVM devices (Amazon.com Amazon EC2 NVMe Instance Storage)
> >> >> Processors: 1, Cores: 2, Threads: 4
> >> >> Intel(R) Xeon(R) Platinum 8124M CPU @ 3.00GHz Stepping 04
> >> >> Memory (MB): 30976 (of 103192), Cache: 7527, Private: 64689
> >> >> 1 x 6400MB [ 7825/ 321/ 1104]
> >> >> 1 x 24576MB [95367/7206/63585] 00:1f.0#1
> >> >> Boot device: [HDD] NVMe: Amazon Elastic Block Store
> >> >> Supported until: Aug 22 2024
> >> >
> >> >That is crazy, and is not a version. It's a "configuration".
> >> it is called version for history reasons...
> >
> >There is no "history" here, you can create whatever sane interface you
> >want right now, there is no backwards compatible issues involved at all.
> you are correct, however, it depends on how much change the hypervisor code requires
> if any (latter is preferable)

I do not understand, again, what tool consumes this today?

> >> >See above, make it text only for the version. If you want to export
> >> >other things, be explicit and make them "one value per sysfs file" or
> >> >use debugfs for debugging things that no one relies on.
> >> so you suggest braking the summery into files, e.g. one for cpus, one for ram and etcetera?
> >
> >Again, who uses this information and what is it used for?
> >
> >thanks,
> >
> >greg k-h
>
> both user who uses the product and the development team.
> it is used to provide a summery of the system. for example, which devices are used
> by the hypervisor.

That's a very odd way to display this as a free-flowing, impossible to
parse, file. Please use something that will be able to be maintained
over time.

thanks,

greg k-h