On Wed, Mar 25, 2020 at 11:22:13PM -0700, Eric Biggers wrote: > > +#ifdef CONFIG_BLK_INLINE_ENCRYPTION > > + /* Inline crypto capabilities */ > > + struct blk_keyslot_manager *ksm; > > +#endif > > I do still wonder whether the concept of inline crypto support should be more > separated from keyslot management, to be better prepared for device-mapper > passthrough support and for hardware that accepts keys directly. (Such > hardware > exists, though I'm not sure support for it will be upstreamed.) For example, > the crypto capabilities could be stored in a 'struct blk_crypto_capabilities' > rather than in 'struct blk_keyslot_manager', and the latter could be optional. > > What you have now is fine for the functionality in the current patchset > though, > so I'm not really complaining. Just something to think about.
I'd rather keep things simple (aka as-is) for now. If needed we can change it. I doubt we'll even have a handful drivers with inline crypto in the next years.. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
