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