linux-kernel - RE: [PATCH 0/7] Enable UFS provisioning via Linux

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <MWHPR04MB11370AED823FB608218CB9AD9A600@MWHPR04MB1137.namprd04.prod.outlook.com>
Date:   Sun, 3 Jun 2018 10:21:17 +0000
From:   Stanislav Nijnikov <Stanislav.Nijnikov@....com>
To:     Evan Green <evgreen@...omium.org>
CC:     Vinayak Holikatti <vinholikatti@...il.com>,
        "jejb@...ux.vnet.ibm.com" <jejb@...ux.vnet.ibm.com>,
        "martin.petersen@...cle.com" <martin.petersen@...cle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        Gwendal Grignou <gwendal@...omium.org>,
        Alex Lemberg <Alex.Lemberg@....com>,
        Avri Altman <Avri.Altman@....com>
Subject: RE: [PATCH 0/7] Enable UFS provisioning via Linux



> -----Original Message-----
> From: linux-scsi-owner@...r.kernel.org <linux-scsi-owner@...r.kernel.org> On Behalf Of Evan Green
> Sent: Friday, June 1, 2018 5:44 PM
> To: Stanislav Nijnikov <Stanislav.Nijnikov@....com>
> Cc: Vinayak Holikatti <vinholikatti@...il.com>; jejb@...ux.vnet.ibm.com; martin.petersen@...cle.com; linux-
> kernel@...r.kernel.org; linux-scsi@...r.kernel.org; Gwendal Grignou <gwendal@...omium.org>; Alex Lemberg
> <Alex.Lemberg@....com>; Avri Altman <Avri.Altman@....com>
> Subject: Re: [PATCH 0/7] Enable UFS provisioning via Linux
> 
> Hi Stanislav. Thanks for taking a look. Responses below.
> 
> On Thu, May 31, 2018 at 3:04 AM Stanislav Nijnikov
> <Stanislav.Nijnikov@....com> wrote:
> >
> > Hi Evan,
> > I have some generic notes:
> > - Why to create new sysfs entries for the configuration descriptor fields if they are just duplication of fields in the device and unit
> descriptors? And the sysfs representation of the device and unit descriptors is existing already.
> 
> Well, UFS describes them as different descriptors. I worry that if I
> add a bunch of clever logic to hide the config descriptor behind other
> descriptors, there might be trouble later if 1) there is a quirky
> device that doesn't reflect the values between descriptors quite the
> same way or at the same time, or 2) if a later UFS spec adds more
> configuration descriptor fields that don't exactly reflect into other
> non-config descriptors, the cleverness will look awkward.
 
No additional logic will be required to attach write functionality to the
existing entries instead of new defined ones. It will reduce the patch 
size significantly. And there will be no need for the unit selector 
mechanism which I'm not sure will be accepted by the SCSI community.

> 
> > - It would be nice to have some "packet" mode allowing to gather configuration changes and apply them at once, not one by one.
> 
> That's definitely doable. Do you think it's needed? I suppose if there
> were a device that truly allowed you to do only a single write to the
> config descriptor, then the commit style would be needed. The two
> devices I've tested (Toshiba and Samsung) allow multiple writes to the
> config descriptor, which makes me lean towards not needing the
> batch-and-commit style, since if you get interrupted you can simply
> try again. I'm happy to do either, though.

Agree. It doesn't have to be part of this patch set. It's just thoughts  
about "quirky devices and future changes" :) that might require to 
change several parameters simultaneously.

> 
> > - Why to put documentation update in the separate patches?
> Well, in case some piece of this turned out to be controversial, I
> wanted to allow for the option of taking these changes independently,
> without the concern of missing the documentation. I'm happy to squash
> all the documentation changes into one if that's preferred.
> 
> -Evan

Regards
Stanislav