rust3ds / shim-3ds Goto Github PK

postix_memalign is not available by default so Rust3DS forked the system allocator:
rust3ds/alloc_system3ds#6

I was curious why we don't have to register our own allocator, and the reason is that this crate adds postix_memalign for the upstream system allocator to use.

From discussion starting at Meziu/rust-horizon#6 (comment)

Looking at the implementation of osGetTime (which is used by gettimeofday, which in turn is used by our clock_gettime impl for CLOCK_REALTIME), they appear to do some adjustment for clock drift in an attempt to get monotonic values, but I'm not sure if that implies the value from svcGetSystemTick() is not normally monotonic? There is also an epoch adjustment from 1900 to 1970 here for gettimeofday, but I don't think that would be strictly needed for a monotonic clock_gettime...

So maybe we could try our own impl that basically looks like this?

let now = svcGetSystemTick();
// Not sure if the math is quite right but you get the idea...
(*tp).tv_sec = now / SYSCLOCK_ARM11;
(*tp).tv_nsec = 1000 * (now - SYSCLOCK_ARM11*(*tp).tv_sec) / CPU_TICKS_PER_USEC;

I have to imagine that svcGetSystemTick() is monotonic, since I think it's supposed to be the number of clock cycles since boot, based on this docstring

Originally posted by @ian-h-chamberlain in Meziu/rust-horizon#6 (comment)

I can work on this soon but wanted to track it here, also wanted to wait for the discussion in #8 to be finalized so we can come up with a best practice for exposing libctru APIs through libc like this, since the error handling will probably be similar.

I think this crate makes more sense for the stubs we have in ctru-rs' test runner:

https://github.com/rust3ds/ctru-rs/blob/master/ctru-rs/src/test_runner.rs#L82-L100

That particular case was a quick fix since nothing linked those symbols before we added extern crate test, but they could prove useful for other cases too.

Obviously this would result in duplicate symbols briefly so we would need to make the change simultaneously here and remove there for it to work.

There's a few names rolling around in this crate at the moment:

• rust-linker-fix-3ds is the name of the repo, which is a bit long
• linker-fix-3ds is the name of the Cargo package (what would go on https://crates.io)
• linker_fix_3ds is the name of the crate, although this doesn't matter much since most consumers would never use it directly (except maybe as extern crate)

I think it would be good to be consistent and use the same name everywhere. We already have a convention of using - rather than _ for these crates, so I think we should probably stick with that. Some options:

• Simply linker-fix-3ds for https://crates.io as well as the repo name. This is the least amount of change from what we have
• libc-3ds. I think this describes what the crate does reasonably well (fills out missing libc APIs) and is nice and short but easily searchable. Doesn't exist yet: https://crates.io/search?q=libc-3ds
  • libc-3ds-rs maybe if we want to make it super obviously Rust, but I think being in the rust3ds org is probably good enough to make that clear
• ??? Open to other options

It looks like libctru has implemented the clock_gettime syscall now: devkitPro/libctru@813d28d

As much as I prefer to have things implemented in Rust, it's probably best if we defer stuff like this to the canonical implementation upstream and reduce the surface area of this crate. We'll have to wait for a new release of libctru (which means we probably also should document some minimum required version of libctru somewhere...)