Simplifying backend selection

[tarcieri]

curve25519-dalek currently defines the following backends, modeled as crate features:

• u32_backend
• u64_backend
• fiat_u32_backend
• fiat_u64_backend
• simd_backend
• avx2_backend

First, avx2_backend can be removed: it's a deprecated legacy alias for simd_backend.

Second, I think u32_backend and u64_backend could be selected automatically by gating on e.g. cfg(target_pointer_width = "64"). If this selection were automatic, I think these features could be removed completely, with u32_backend/u64_backend selected and used by default unless another backend has been explicitly enabled.

Likewise, fiat_u64_backend and fiat_u32_backend can be collapsed down to fiat_backend using similar target_pointer_width-based gating.

If all of the above were done, the list above could be simplified down to just fiat_backend and simd_backend.

[nox]

Any chance to make the crate use additive features?

[tarcieri]

The best way to do that would probably be to get rid of feature-gating for simd_backend, and instead use runtime autodetection to choose when to enable it.

Then the only backend feature left is fiat_backend, which could override the other backends at compile-time.

[ryankurte]

If this selection were automatic, I think these features could be removed completely, with u32_backend/u64_backend selected and used by default unless another backend has been explicitly enabled.

so long as there's still an override / way to disable the detection! sometimes it's useful to be able to run tests for 32-bit platforms under x86_64 with the u32_backend, and where target detection is involved, cpuid tends to break in miri and enclave builds...

Any chance to make the crate use additive features?

i was wondering whether y'all had considered refactoring the backends to traits w/ implementations so you could build the library with any / all enabled, then default based on runtime detection or availability? similar to the way allocators are implemented now. i looked at starting / PRing this briefly but, it would be a lot of work without knowing it'd be useful / desirable.

[tarcieri]

so long as there's still an override / way to disable the detection! sometimes it's useful to be able to run tests for 32-bit platforms under x86_64 with the u32_backend

FWIW, we used to have explicit features for this in the https://github.com/RustCrypto/elliptic-curves crates, but got rid of the because you can test 32-bit code on 64-bit Linux by compiling for --target i686-unknown-linux-gnu, or using cross.

and where target detection is involved, cpuid tends to break in miri and enclave builds...

We have a lot of experience with runtime feature detection in @RustCrypto using the cpufeatures crate which is on-by-default for many crates, including aes, chacha20, poly1305 and polyval, where chacha20 and poly1305 have explicit AVX2 backends.

cpufeatures already handles SGX and Miri by disabling runtime detection in these environments. SGX can still take advantage of specific features by enabling them as cargo features.

i was wondering whether y'all had considered refactoring the backends to traits w/ implementations so you could build the library with any / all enabled

That seems pretty onerous. Many, many types would need a generic parameter for the backend, and there would need to be different backends for e.g. base and scalar fields.

I think it's a lot simpler to make backend selection as automatic as possible, keeping all the complexity hidden so people don't have to think about it.

[tarcieri]

Now I remember the simd_backend feature is still needed as it's nightly-only.

I still think it's best for it to employ autodetection, but unfortunately that does still leave two features which are mutually incompatible (simd_backend and fiat_backend)

[nox]

Now I remember the simd_backend feature is still needed as it's nightly-only.

Then it should be a --cfg flag you pass through RUSTFLAGS, it should not be a feature.

[tarcieri]

Yeah, that's what we've started doing in the @RustCrypto crates. We've had a few complaints that it's hard to configure --cfg attributes but it seems better than dealing with clashing feature activations

[tarcieri]

PR with an initial minimal implementation here: #428