Provide a custom getrandom (crate) implementation

[AzureMarker]

The getrandom crate fails to compile for unsupported systems (they don't blanket support unix-like systems), but it has a mechanism we can use to register a custom backing implementation:
https://docs.rs/getrandom/latest/getrandom/#unsupported-targets
https://docs.rs/getrandom/latest/getrandom/macro.register_custom_getrandom.html

We could implement this in ctru-rs and users would be able to use getrandom without issues.

Alternatively (and maybe in parallel), we could make a PR to getrandom to add support. We'd have to make sure to only depend on libc::get_random and not libctru.

[Meziu]

We could make a module for third-party crate implementations, that looks to be a common thing we’ll have to do. Still, I bet that after getting an STD PR merged other crate distributors will be ok with the further support.

[AzureMarker]

BTW one reason we'd want this is to inspect running programs using tokio-console:
https://github.com/tokio-rs/console/tree/main/console-subscriber
It uses getrandom in its dependency tree. But there's some more blockers (it uses std threads, so we'd need #45).

[Meziu]

Functions can only be registered in the root binary crate. Attempting to register a function in a non-root crate will result in a linker error. This is similar to #[panic_handler] or #[global_allocator], where helper crates define handlers/allocators but only the binary crate actually uses the functionality.

From getrandom's docs. Makes sense honestly. It looks like they are keen on supporting new targets though. We should PR once the std is merged.

[AzureMarker]

We should PR once the std is merged.

We could technically make a PR beforehand since it's a no_std crate and just uses libc. But std is more of a priority.

[AzureMarker]

@Meziu I'm working on a getrandom PR btw. It should be quick, and it unblocks using some third party crates.

[AzureMarker]

Opened rust-random/getrandom#248

I realized we need to make another PR to libc before it can get merged, since upstream libc doesn't have getrandom yet. The PR is in draft until that happens.

[Meziu]

Cool! Hope it goes well. I am still wondering about making having the PS service automatically run (since it’s fundamental to std and libc features), but we would need to find a way to hold it statically and drop it at the program’s end.

[AzureMarker]

I'm not sure if atexit is implemented, but that might work.

[Meziu]

I'm not sure if atexit is implemented, but that might work.

It is! I remember some example using it to close the gfx service now that I think about it, we can do that!

[AzureMarker]

This got merged and is now released in getrandom 0.2.6!