> > > > > 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. Ack on that. For me, it was very clear that Bart prefers the Samsung approach, Hence I withdrew from my RFC and switch to support Daejun's. Thanks, Avri