linux-kernel - Re: [RFC PATCH v2 3/5] scsi: ufs: Introduce HPB module

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]

Date:   Thu, 18 Jun 2020 10:06:04 +0900
From:   Daejun Park <daejun7.park@...sung.com>
To:     Bean Huo <huobean@...il.com>,
        Daejun Park <daejun7.park@...sung.com>,
        Avri Altman <Avri.Altman@....com>,
        ALIM AKHTAR <alim.akhtar@...sung.com>,
        "jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
        "martin.petersen@...cle.com" <martin.petersen@...cle.com>,
        "asutoshd@...eaurora.org" <asutoshd@...eaurora.org>,
        "beanhuo@...ron.com" <beanhuo@...ron.com>,
        "stanley.chu@...iatek.com" <stanley.chu@...iatek.com>,
        "cang@...eaurora.org" <cang@...eaurora.org>,
        "bvanassche@....org" <bvanassche@....org>,
        "tomas.winkler@...el.com" <tomas.winkler@...el.com>
CC:     "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Sang-yoon Oh <sangyoon.oh@...sung.com>,
        Sung-Jun Park <sungjun07.park@...sung.com>,
        yongmyung lee <ymhungry.lee@...sung.com>,
        Jinyoung CHOI <j-young.choi@...sung.com>,
        Adel Choi <adel.choi@...sung.com>,
        BoRam Shin <boram.shin@...sung.com>
Subject: Re: [RFC PATCH v2 3/5] scsi: ufs: Introduce HPB module

> > > implemented
> > > > as a module parameter, so that it can be configurable by the
> > > > user.
> > > > 
> > > > To gurantee a minimum memory pool size of 4MB:
> > > > $ insmod ufshpb.ko ufshpb_host_map_kbytes=4096
> > > 
> > > You are going through a lot of troubles to make it a loadable
> > > module.
> > > What are, in your opinion, the pros and cons of this design
> > > decision?
> > 
> > In my opinion...
> > 
> > pros:
> > 1. A user can unload an unnecessary module when there is an
> > insufficient
> > memory situation (HPB case).
> > 2. Since each UFS vendor has a different way of implementing UFS
> > features,
> > it can be supported as a separate module. Otherwise, many quirks must
> > be attached to module, which is not desirable way.
> > 3. It is possible to distinguish parts that are not necessary for
> > essential
> > ufs operation.
> > 4. It is advantageous to implement the latest functions according to
> > the
> > development speed of UFS.
> > 
> > cons:
> > 1. It is difficult work to be implemented as a module.
> > 2. Modifying "ufsfeature.c" is required to implement the feature that
> > can
> > not supported by the exsiting "ufsf_operation".
> > 
> > Thanks,
> > Daejun
> 
> Dear Avri, Daejun, Bart
> 
> It is true that it is very difficult to make everyone happy.
> We now have three HPB drivers in the patchwork, but I still didn't see
> a final agreement. Please tell me which one do you want to focus on?
The HPB driver has been greatly improved in the process of being applied to
mobile devices since the release of the first HPB version in openMPDK. We
want to contribute to the linux mainline with the knowledge obtained
through the experience.
I find it difficult to make everyone happy, but I think it is possible that
everyone can accept the HPB driver through several revisions.

Thanks,
Daejun