-
Notifications
You must be signed in to change notification settings - Fork 425
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
no-std
support for hickory-proto
#2104
base: main
Are you sure you want to change the base?
Conversation
Who is us? What is your use case for this? If we're going to review this, it would be nice to get it split into smaller commits that do one thing instead of one big wad of code -- would you be up for that? |
Thank you for your prompt response! The use-case is parsing DNS responses in an RTOS (so no rust stdlib support). I'll be glad to work on this / split it up into chunks, if there is interest to land (parts of) this PR from your end |
This is a really big change right now. I think having no-std makes sense, but is definitely going to be challenging to land this in its current form. I wonder if there is a simpler pass that could be taken, where the initial start is in the Cargo.toml, and then focusing a series of PRs on allowing different modules to be ok without the It sounds like you're open to doing that work, and it might get us to a better spot with less overhead from a review prespective? Also, it would probably help with passing all the different test cases. |
As far as I can see, the testcases fail right now because of unstable features in use. We can totally move to |
yeah, |
I think the path here is smaller "horizontal" changes, like:
These help us move to (We've been going through a similar strategy in the rustls project.) |
This is a rather big pull request that allows the use of
hickory-proto
inno_std
environments.It has been tested on an embedded system and works, however there are certain gotchas, listed below.
Hence, this PR is marked as draft and we hope to hear some maintainer feedback on it.
Some gotchas are as follows:
no-std
support requires nightly features. We have feature-gated those behind anunstable
feature. Thestd
feature doesn't require nightly - everything works as normal here. The nightly features we need are:ip_in_core
for all ip and network address related APIs (Tracking Issue for ip_in_core rust-lang/rust#108443)error_in_core
for error handling without std (Tracking Issue forError
incore
rust-lang/rust#103765)no_std
support for theurl
crate servo/rust-url#831.thiserror_core
, a no-std compatible version ofthiserror
on cargo.seed_rng
One possible way forward, instead of going all-in on, could be to merge the
unstable
as well asstd
features from this PR and theno_std
header (including allvec
andstring
imports), but continue to depend on the upstreamurl
andthiserror
crates, so that ano_std
forks is easier to maintain (by changing the imports in Cargo.toml)Please let us know what you think :)