lkml.org 
[lkml]   [2022]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v2] drivers/virt/vSMP: new driver
Date
>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?
there are monitoring utils that parses it.
see comment below for more on this

>
>> >> >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

your suggestion to brake the configuration seems sound, we will implement that and
provide a new patch

Thanks for the reviews.

Eial
\
 
 \ /
  Last update: 2022-08-25 14:39    [W:0.224 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site