On Thu, 29 May 2025 at 14:16, Eric Biggers <ebigg...@kernel.org> wrote:
>
> So using crc32c() + ext4 + x86 as an example (but SHA-256 would be very
> similar), the current behavior is that ext4.ko depends on the crc32c_arch()
> symbol.
Yes, I think that's a good example.
I think it's an example of something that "works", but it certainly is
a bit hacky.
Wouldn't it be nicer if just plain "crc32c()" did the right thing,
instead of users having to do strange hacks just to get the optimized
version that they are looking for?
> Does any of the infrastructure to handle "this symbol is in multiple modules
> and
> they must be loaded in this particular order" actually exist, though?
Hmm. I was sure we already did that for other things, but looking
around, I'm not finding any cases.
Or rather, I _am_ finding cases where we export the same symbol from
different code, but all the ones I found were being careful to not be
active at the same time.
I really thought we had cases where depending on which module you
loaded you got different implementations, but it looks like it either
was some historical thing that no longer exists - or that I need to go
take my meds.
> IMO this sounds questionable compared to just using static keys and/or
> branches,
> which we'd need anyway to support the non-modular case.
I really wish the non-modular case used static calls, not static keys
like it does now.
In fact, that should work even for modular users.
Of course, not all architectures actually do the optimized thing, and
the generic fallback uses indirect calls through a function pointer,
but hey, if an architecture didn't bother with the rewriting code that
is fixable - if the architecture maintainer cares.
(On some architectures, indirect calls are not noticeably slower than
direct calls - because you have to load the address from some global
pointer area anyway - so not having the rewriting can be a "we don't
need it" thing)
Linus
