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
