Hi, On 8/5/25 13:58, Eric Biggers wrote:
What does this have to do with this thread, which is about the PowerPC optimized MD5 code?
Hence the new subject. It is still related to removal of code, but asks about the bigger picture.
The code removal changes you've been pushing lately absolutely make sense in the context of "the crypto subsystem is for internal use by the kernel, and all known users will only ever submit small work items."
However, there is also the userspace API, and hardware accelerators also register with the crypto subsystem, so it is *also* the way for userspace to use specialized hardware.
If these are separate, then it makes sense to acknowledge that the kernel will never use asynchronous transforms for anything, simplify the internal API, and move all the hardware support to a separate registry that is for userspace applications only.
However if we don't want separate registries, then it makes no sense for the kernel to set policy for userspace here; it should offer all the alternatives. The kernel can, and should, define policy for itself, and I wholeheartedly agree that offloading small requests does not make sense, unless we're on battery power.
I'm also not convinced that fscrypt cannot ever learn to submit a single large request or a large batch of small requests if it is asked to decrypt a large file, so in my opinion the common registry makes more sense.
Making sure that hardware support actually works and is tested is the responsibility of the driver and port maintainers. We understand that subsystem maintainers do not have all the hardware available, but the same goes for all the other subsystems -- the DRM maintainers routinely merge drivers for hardware they do not own, because the changes come from people who *do* own the hardware, and have tested the changes.
The latter is a project management issue, mostly: if there is a lack of working relationships with driver and port maintainers, then that needs to be fixed, not assumed to be an unchangeable part of the environment that technical decisions are made in.
Simon
