On Wed, Jan 08, 2020 at 06:05:56AM -0800, Christoph Hellwig wrote: > I haven't been able to deep dive into the details, but the structure > of this still makes me very unhappy. > > Most of it is related to the software fallback again. Please split the > fallback into a separate file, and also into a separate data structure. > There is abslutely no need to have the overhead of the software only > fields for the hardware case. > The fallback actually is in a separate file, and the software only fields are not allocated in the hardware case anymore, either - I should have made that clear(er) in the coverletter. > On the counter side I think all the core block layer code added should > go into a single file instead of split into three with some odd > layering. > Alright, I'll look into this. I still think that the keyslot manager should maybe go in a separate file because it does a specific, fairly self contained task and isn't just block layer code - it's the interface between the device drivers and any upper layer. > Also what I don't understand is why this managed key-slots on a per-bio > basis. Wou;dn't it make a whole lot more sense to manage them on a > struct request basis once most of the merging has been performed? I don't immediately see an issue with making it work on a struct request basis. I'll look into this more carefully. Thanks! Satya
