On Wed, Sep 29 2021 at 12:35P -0400, Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > From: Eric Biggers <ebiggers@xxxxxxxxxx> > > blk_keyslot_manager is misnamed because it doesn't necessarily manage > keyslots. It actually does several different things: > > - Contains the crypto capabilities of the device. > > - Provides functions to control the inline encryption hardware. > Originally these were just for programming/evicting keyslots; > however, new functionality (hardware-wrapped keys) will require new > functions here which are unrelated to keyslots. Moreover, > device-mapper devices already (ab)use "keyslot_evict" to pass key > eviction requests to their underlying devices even though > device-mapper devices don't have any keyslots themselves (so it > really should be "evict_key", not "keyslot_evict"). > > - Sometimes (but not always!) it manages keyslots. Originally it > always did, but device-mapper devices don't have keyslots > themselves, so they use a "passthrough keyslot manager" which > doesn't actually manage keyslots. This hack works, but the > terminology is unnatural. Also, some hardware doesn't have keyslots > and thus also uses a "passthrough keyslot manager" (support for such > hardware is yet to be upstreamed, but it will happen eventually). > > Let's stop having keyslot managers which don't actually manage keyslots. > Instead, rename blk_keyslot_manager to blk_crypto_profile. > > This is a fairly big change, since for consistency it also has to update > keyslot manager-related function names, variable names, and comments -- > not just the actual struct name. However it's still a fairly > straightforward change, as it doesn't change any actual functionality. > > Acked-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx> # For MMC > Signed-off-by: Eric Biggers <ebiggers@xxxxxxxxxx> Unfortunate how fiddley this change forced you to get but it looks like you've done a very solid job of cleaning it all up to be consistent. Reviewed-by: Mike Snitzer <snitzer@xxxxxxxxxx>
