Brian Smith

https://github.com/google/zerocopy/issues/450 tracks changes to zerocopy to support this. MSRV was bumped to 1.61.0 in *ring* in part to make it possible to use zerocopy.

OK, after looking at everything (I think), I think the long-term solution is to "just" eliminate `ring::endian` completely. * Refactor `ring::aead` to remove the `Block` type. I have some (old)...

Note to help explain why `ring::endian` exists in the first place: We try to keep the data structure definitions used to define the interface to the BoringSSL C/assembly functions "equivalent,"...

I did a sketch of this tonight and it's 159 insertions(+), 176 deletions(-) including license boilerplate so I think it is very practical to eliminate almost all of `ring::endian`, and...

So, what did we learn from this?: * It seems easier easier for the zerocopy developers to change *ring* to use zerocopy than it is to "just" eliminate the need...

> Thanks. It builds fine on FreeBSD aarch64 with rust 1.63.0. There is a warning though: Thanks! That means the new logic isn't being used, and the reason is that...

I rebased this. Now our MSRV is 1.60 so we can move forward with this.

Thanks @complexspaces. Because so much was refactored in this module, a non-trivial rebase of this on top of main is needed. I suspect the assertion you are hitting is: ```...

The reason this PR failed in CI is because CI had a MSRV of 1.60.0 when this was submitted, and there was a bug in 1.60.0 and earlier in the...

Closing this for now. We've implemented some workarounds for rust-lang/rust issues that we can't implement on top of `is_aarch64_feature_detected`, and I have some vague plans for new functionality that probably...