lkml.org 
[lkml]   [2020]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH v2 3/5] scsi: ufs: Introduce HPB module
From
Date
On Wed, 2020-06-17 at 19:30 +0900, Daejun Park wrote:
> > > 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?

Bean

\
 
 \ /
  Last update: 2020-06-17 20:56    [W:0.128 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site