-
Notifications
You must be signed in to change notification settings - Fork 10
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
Rng: Add prng, hwrng support #54
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't plowed through the random.rs yet, but do I get this right that while hwrng.rs and prng.rs's rand_prng already give the user all they need, the riot_prng (backed by random.rs) is "only" there to avoid pulling in code for StdRng in situations when RIOT's rng is either already there or for other reasons works better than the pure Rust version?
(The "only" is in quotes because these are legitimate reasons; I wonder though whether we should have unified API, and what can be done to make this more visible.)
src/prng.rs
Outdated
/// See this modules description regarding quality of the used seeds. | ||
pub fn rand_prng() -> StdRng { | ||
let mut buffer = [0u8; 32]; | ||
unsafe { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need for unsafe here; as per above the error type is uninhabited, the error handling will just collapse.
(And if the RIOT HWRNG ever does become fallible, we'll get a clean crash rather than UB).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed in 2b99ee5
* remove unsafe blocks * make error type empty * update comments
src/lib.rs
Outdated
@@ -146,6 +146,15 @@ pub mod socket_embedded_nal_tcp; | |||
#[cfg(riot_module_periph_gpio)] | |||
pub mod gpio; | |||
|
|||
#[cfg(riot_module_periph_hwrng)] | |||
pub mod hwrng; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I understand, the sensible way to use all of this is through the prng module.
Is there any good reason that the hwrng module and the random module are pub in the first place, or that RandomSeed::new_from_hwrng would be public?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it is intended to be used through prng
. I just left the rest public in case someone might need it e.g to seed his own prng but we could make it private to make people use the "intended" way. I do not have a strong opinion on that matter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then please limit the public parts. Public APIs that are not used are a needless compatibility liability -- whereas the two functions that will stay pub can easily be maintained. If it turns out that any part of this is needed, it's still easy to make a few more parts pub, whereas going back on that is a breaking change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made the two modules random
and hwrng
private
Is this even still relevant with the other random module now present in the wrappers? As far as I can see they both do roughly the same with the main differences being:
Depending on any of the above being desirable this PR could just be closed or some of the changes could be merged into the current solution. |
This is an idea to provide prngs seeded by RIOTs
hwrng
interface. This usesrandom
as one prng.In addition I implemented
rand:RngCore
andrand::SeedableRng
withrandom
to provide therand::Rng
interface to be usable here. Also a function is provided to seed anrand::StdRng
(Seems not need std despite its name) withhwrng
to have two different prngs at hand.The
rand
part was mostly added because I like the interface ofrand::Rng
but it's just an idea and it definitely needs to be discussed if it is worth the extra dependencies. Or maybe should be behind a feature.Structure looks like this:
hwrng.rs
: Wrapper aroundhwrng
interfacerandom.rs
: Wrapper aroundrandom
module + implementation ofrand
interfacesprng.rs
: User faced helper methods to create a prng viahwrng
seedingEdit: This needs a change in
rust-riot-sys
to create bindings torandom
(See RIOT-OS/rust-riot-sys#26)