Blocked by rustls/rustls#2068

I have been really busy working on rustls/rustls#2200 to enable building rustls for this kind of target. This is almost ready, with a few remaining XXX / TODO items that I would like to resolve soon. And I have a similar update for rustls-rustcrypto provider working here: brodycj/rustls-rustcrypto#1

Bad news is that there may be some resistance due to the requirement for Rust nightly & issue with the built-in rustls providers: rustls/rustls#2068 (comment)

requires Rust nightly version

Perhaps this isn't a feature ready for mainline Rustls in this case?

One issue is that I had some trouble building the built-in aws-lc-rs & ring providers with the no atomic ptr targets.

I have similar feelings here. If this only works with rustls-rustcrypto, and not the two mainline crypto providers, is it ready to ship?

If they would reject my proposal or put it on hold, this would continue to block progress here.

I personally cannot see why they should reject a feature that could help some people in the embedded Rust community, even if the feature is clearly documented as an "unstable" feature that should only affect those who want to use the feature.

I would really appreciate it if anyone could help support my case to get my proposal accepted and included.

I would surely hate it if we could not use rustls without forking it.

Please note my questions shouldn't be read as intent to reject the proposal. I'm only one maintainer and don't set the project direction. I also haven't made a personal conclusion of whether it should/shouldn't be accepted, I'm only asking questions I think are relevant to evaluating the state of the work as part of a broader discussion.

updated response: @cpu I would like to propose we keep the discussion in rustls/rustls#2068 for now, I think all the info I wrote here should now be in my comment on rustls/rustls#2068

old response:

Thanks @cpu, sorry I didn't see your comment before commenting in the other thread - rustls/rustls#2068 (comment) - quoting most of it here:

I was hoping to contribute this feature as an unstable feature, and I think there is plenty of precedence for supporting unstable feature options. Here are a couple prime examples that I found from a very quick search, which happen to be within the Rust ecosystem:

• https://doc.rust-lang.org/cargo/reference/unstable.html - unstable features in Rust itself
• https://docs.deno.com/runtime/reference/cli/unstable_flags/

Yes there would be some special requirements for those who wish to start using this proposed feature, which I don't think should affect anyone else not using this feature.

The one minor caveat I can think of is that someone building rustls with --all-features flag would be affected by this feature. But considering that rustls is a library, I think this could only be an issue with someone building rustls as a stand-alone library build, NOT someone including rustls as a dependency for a higher-level application or library.

@cpu @bjoernQ I don't know which thread would be best for us to continue discussion in, or if it may be better to continue discussion in the PR itself - rustls/rustls#2200

I think the biggest impact could be in the following kinds of stand-alone rustls library builds:

• build with all features - I would love to find a way to enable building with all stable features
• build with proposed critical-section feature - this would require --cfg option to get the required support from portable-atomic-util::Arc

Alternative could be to use an unstable cfg feature, like I did in this released contribution: taiki-e/portable-atomic#195

P.S. I will be unplugging in the next couple hours, back online sometime during the weekend.

I don't know which thread would be best for us to continue discussion in, or if it may be better to continue discussion in the PR itself - rustls/rustls#2200

Let's continue in Rustls#2200 - I just wanted to add context here before anyone got too worked up about an outcome that isn't decided.