Horizon (Nintendo 3DS) getrandom function and fixes
This PR adds `getrandom`, conforming to the [Linux spec](https://man7.org/linux/man-pages/man2/getrandom.2.html), to the `horizon` OS (Nintendo 3DS).
The 3DS doesn't have a full libc implementation, and its randomness API is pretty complicated: https://github.com/rust-random/getrandom/pull/248. For this reason (see the linked PR for more details), the randomness implementation is abstracted by using the Linux `getrandom` interface.
This PR also fixes some types on the horizon platform. See the commits and diff.
cc: `@ian-h-chamberlain` `@Meziu`
Horizon (Nintendo 3DS) pthread functions and non-portable extensions
This PR adds some standard and nonstandard pthread/threading functions to the horizon (Nintendo 3DS) operating system. This will allow us to open a PR to std for std threads support.
The Nintendo 3DS doesn't have a full libc implementation, so there are some user libraries which implement part of libc, such as libctru:
https://github.com/devkitPro/libctru
For some more context on this situation, see https://github.com/rust-random/getrandom/pull/248
But std doesn't want to interface directly with anything that could be seen as using the "internal" interfaces of the 3DS or consoles in general:
https://github.com/rust-lang/rust/pull/88529#issuecomment-919938396
So we work around this by implementing standard pthread interfaces, plus some nonstandard ones as necessary, and expose that interface to std:
https://github.com/Meziu/pthread-3ds
Here's the justifications for the nonstandard interfaces:
* `pthread_attr_setprocessorid_np` (and the `get` version):
The 3DS requires the core a thread runs on to be specified at thread creation time. I'm pretty sure you can't migrate threads across cores. Additionally, the cores act differently (ex. one core is cooperatively scheduled). This means we need to have an API to set the core to use in the thread attributes struct. We didn't find any relevant standard API for this, so we added a nonstandard one.
* `pthread_getprocessorid_np`:
The 3DS lets you get the core/processor ID of the executing thread. But it doesn't have a function to get the core ID of any arbitrary thread. We didn't find any standard APIs which would match these semantics, so we added a nonportable one. Once place this API is used is to get the default core/processor ID when spawning a thread (spawn the thread on the current processor).
For more context, see:
* https://github.com/Meziu/rust-horizon/pull/10
* Especially https://github.com/Meziu/rust-horizon/pull/10#issuecomment-1037026221
* https://github.com/rust-random/getrandom/pull/248
cc: `@ian-h-chamberlain` `@Meziu`
Correct the size of certain types on espidf platform
This was initially discovered in https://github.com/esp-rs/rust/issues/92, the reason stat fails on the esp-idf platform is because the `stat` struct has a different layout on the Rust side compared to the C side.
I chose the scheduler priorities based on
https://man7.org/linux/man-pages/man7/sched.7.html
I think the cooperative app cores are most like SCHED_FIFO, while the
sys core is similar to SCHED_RR.
However, I don't think our pthread implementation would be able to
accurately return the right policy since we need to know what processor
the thread is running on, and the only API to get that gets the ID for
the current thread. Since the pthread function passes in a thread ID, we
are unable to always get the processor ID and thus the policy.
In this case, I think we should just always return (and accept in set)
SCHED_FIFO. I don't think this will be used anyways.
The pthread_attr_t type can have priority and affinity values set.
pthread_getpriority returns the priority of the current thread.
These are needed to enable std thread support. std can't link directly
with libctru so we go through pthread as an intermediate interface.
Add Linux BLKIOMIN and BLKIOOPT ioctl constants
These ioctl constants are used to fetch the minimum and optimal I/O
sizes for block devices.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
