Switch rand_os to use fuchsia-cprng crate in rand-0.6#706
Merged
dhardy merged 1 commit intorust-random:masterfrom Jan 25, 2019
Merged
Switch rand_os to use fuchsia-cprng crate in rand-0.6#706dhardy merged 1 commit intorust-random:masterfrom
dhardy merged 1 commit intorust-random:masterfrom
Conversation
The fuchsia team has spun out a new crate, [fuchsia-cprng](https://crates.io/crates/fuchsia-cprng), which reduces your exposure to changes in our syscalls, which are still not stable. This crate just exposes the CPRNG syscall, which we do not expect to change. Also note, the underlying syscall, [zx_cprng_draw](https://fuchsia.googlesource.com/zircon/+/HEAD/docs/syscalls/cprng_draw.md) no longer needs the loop. Instead, we guarantee that the buffer always be filled with randomness.
erickt
added a commit
to erickt/rand
that referenced
this pull request
Jan 24, 2019
As in rust-random#706, fuchsia is replacing users of fuchsia-zircon with fuchsia-cprng since that reduces exposure to our changing syscalls.
erickt
added a commit
to erickt/rand
that referenced
this pull request
Jan 24, 2019
As in rust-random#706, fuchsia is replacing users of fuchsia-zircon with fuchsia-cprng, since that reduces exposure to our changing syscalls. If this is accepted, could a new version be cut?
Contributor
Author
|
I think the travis failure is unrelated to this PR. I poked around, and it looks like it's unrelated broken doc links. I filed #710 to track it. |
Member
|
Okay, nice! Why do you still have users on such old versions of Rand?
|
Contributor
Author
|
Thanks @dhardy! Unfortunately we have a bunch of dependencies that are still using the older versions: On 0.3:
On 0.4:
On 0.5:
It just takes time for us to get upstream packages to update, then get their dependents to update, and etc. |
erickt
added a commit
to erickt/rand
that referenced
this pull request
Jan 25, 2019
As in rust-random#706, fuchsia is replacing users of fuchsia-zircon with fuchsia-cprng since that reduces exposure to our changing syscalls.
erickt
added a commit
to erickt/rand
that referenced
this pull request
Jan 25, 2019
As in rust-random#706, fuchsia is replacing users of fuchsia-zircon with fuchsia-cprng, since that reduces exposure to our changing syscalls. If this is accepted, could a new version be cut?
erickt
added a commit
to erickt/rand
that referenced
this pull request
Jan 28, 2019
I missed that rand got refactored, and the fuchsia update in rust-random#706 should have triggered a release for rand_os, not rand.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The fuchsia team has spun out a new crate, fuchsia-cprng, which reduces your exposure to changes in our syscalls, which are still not stable. This crate just exposes the CPRNG syscall, which we do not expect to change.
Also note, the underlying syscall, zx_cprng_draw no longer needs the loop. Instead, we guarantee that the buffer always be filled with randomness.
If this patch is accepted, would it be possible to get a release of rand_os? We also have some dependencies that are using 0.3, 0.4, and 0.5, so would you also be interested in patches for those versions as well?
Thanks!