lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <PAXPR02MB73108383655C1FB4B98C3C2281729@PAXPR02MB7310.eurprd02.prod.outlook.com>
Date:   Thu, 25 Aug 2022 10:41:28 +0000
From:   "Czerwacki, Eial" <eial.czerwacki@....com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Arsh, Leonid" <leonid.arsh@....com>,
        "Twaig, Oren" <oren.twaig@....com>,
        SAP vSMP Linux Maintainer <linux.vsmp@....com>,
        Arnd Bergmann <arnd@...db.de>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        Andra Paraschiv <andraprs@...zon.com>,
        Borislav Petkov <bp@...e.de>,
        Brijesh Singh <brijesh.singh@....com>,
        Eric Biggers <ebiggers@...gle.com>, Fei Li <fei1.li@...el.com>,
        Hans de Goede <hdegoede@...hat.com>,
        Jens Axboe <axboe@...nel.dk>,
        Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
Subject: Re: [PATCH v2] drivers/virt/vSMP: new driver

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

>
>You have a version up there, just export that as a simple string
>"10.6.2862.0".  What is the rest of that stuff needed for?  Who will use
>it?  Should it just be in a debugfs file for debugging things?
this allows the user and us to know what is the system configuration
in a user friendly ui. it isn't for debugging.
it can be rename to summery instead of version but it is needed
to be accessible all the time, sysfs was a logical location because
afaik, it is less probable to have a system without debugfs rather than
one without sysfs

>
>Oh, and I love the "Supported until" tag, that's funny :)
today's comic relief :)

>
>> >> that is why I decided to go with binary, I understood that the text is rather limited.
>> >
>> >That is true, sysfs is "one value per file", this can not be a file that
>> >you parse.
>> should I keep it as bin then?
>
>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?

>
>> >You have pdev, use that in your dev_dbg() call.
>> I have pdev when the probe cb is called, however in other funcs I
>> don't have it.
>
>That's for the other functions to fix up.  Pass in the device pointer to
>them.  You are a driver, there is no reason to NOT have a device pointer
>in your functions, otherwise you are operating on global state which a
>driver should never do.  You will notice that quickly when you remove
>the static variable at the top of the file like I asked you to :)
>
>thanks,
>
>greg k-h

understood.

Thanks,

Eial

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ