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

[Stanislav Nijnikov]

Hi Adrian,

> -----Original Message-----
> From: Adrian Hunter <adrian.hunter@xxxxxxxxx>
> Sent: Friday, June 8, 2018 3:31 PM
> To: Evan Green <evgreen@xxxxxxxxxxxx>; Stanislav Nijnikov <Stanislav.Nijnikov@xxxxxxx>
> Cc: Vinayak Holikatti <vinholikatti@xxxxxxxxx>; jejb@xxxxxxxxxxxxxxxxxx; martin.petersen@xxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; linux-scsi@xxxxxxxxxxxxxxx; Gwendal Grignou <gwendal@xxxxxxxxxxxx>; Alex Lemberg
> <Alex.Lemberg@xxxxxxx>; Avri Altman <Avri.Altman@xxxxxxx>
> Subject: Re: [PATCH 0/7] Enable UFS provisioning via Linux
> 
> On 04/06/18 17:59, Evan Green wrote:
> > On Sun, Jun 3, 2018 at 3:21 AM Stanislav Nijnikov
> > <Stanislav.Nijnikov@xxxxxxx> wrote:
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: linux-scsi-owner@xxxxxxxxxxxxxxx <linux-scsi-owner@xxxxxxxxxxxxxxx> On Behalf Of Evan Green
> >>> Sent: Friday, June 1, 2018 5:44 PM
> >>> To: Stanislav Nijnikov <Stanislav.Nijnikov@xxxxxxx>
> >>> Cc: Vinayak Holikatti <vinholikatti@xxxxxxxxx>; jejb@xxxxxxxxxxxxxxxxxx; martin.petersen@xxxxxxxxxx; linux-
> >>> kernel@xxxxxxxxxxxxxxx; linux-scsi@xxxxxxxxxxxxxxx; Gwendal Grignou <gwendal@xxxxxxxxxxxx>; Alex Lemberg
> >>> <Alex.Lemberg@xxxxxxx>; Avri Altman <Avri.Altman@xxxxxxx>
> >>> 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@xxxxxxx> 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.
> >>
> >
> > So this would be modifying the existing sysfs entries so that reads
> > still come from the device and unit descriptors, but writes go to
> > equivalent fields in the config descriptor? I can explore that
> > approach. Alternatively, if the unit selector mechanism is not
> > desired, I could dynamically create sysfs directories for each unit in
> > the config descriptor, but still bring out the config descriptor
> > values as separate entries. (I still worry a bit about smashing the
> > descriptors together as the UFS spec called them out as different).
> 
> If you use the unit attributes, how do you configure units that do not yet
> exist?

For example by adding the enable_lun writeable sysfs entry. I think both ways are
viable and there are several pitfalls in each of them. Now it's up to Evan to decide
how to implement this.

> 
> Perhaps it is better to represent the configuration descriptors exactly as
> they are defined in the specification.  Probably not worth exposing them at
> all if the configuration is locked (attribute bConfigDescrLock == 1).
> 
> Note also that the 2.1 spec. defines  bConfDescContinue which allows updates
> to be grouped and committed together.

The only question is how many devices are ready to get dozens of configuration
descriptors related to first eight LUNs instead just one when this lock is enabled.

Regards
Stanislav