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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux