[Rough draft] [Be gentle] Library to wrap IPC calls

[DeltaF1]

https://github.com/DeltaF1/3ds-ipc-tools

I've been reading the wiki and learning about IPC for a few weeks now, and I decided I wanted to help make it easier to wrap IPC commands that haven't been wrapped by libctru. This is my first time writing unsafe Rust so it might be terrible, but I wanted to get feedback on whether this is something that you would like included in ctru-rs/ctru-sys at some point, and any suggestions for making the API nicer. I wrote up an example of how one might use the library alongside the 3dbrew wiki in https://github.com/DeltaF1/3ds-ipc-tools/blob/main/Readme.md.

• It seems like my borrow shenanigans with TranslateParams do work to keep the references borrowed for the liftetime of the struct, but I am not super confident about it. Can anyone with more experience than me confirm that I've done that right or if I'm missing something?
• I don't really understand how errors work in ctru-rs. in some contexts I can do ResultCode(res)? but sometimes the type checker gets mad at me and I don't know why lol. Should all my functions with errors return ctru::Result<T> or is Result<T, ctru_sys::Result> useful?
• If you can see any conceptual errors about how IPC/translate parameters/static buffers work, I'd really like to know. This stuff has been hard to grok and I have re-read the IPC wiki page many times trying to figure out behaviour...
• Ideally I'd like to add the TLS methods like getThreadCommandBuffer to ctru-sys as per Expose static inline functions to bindings #123. I ended up implementing them myself with assembly for now (and then realized that AzureMarker did the same thing in Add an ir:USER service wrapper and Circle Pad Pro example #86). Hopefully those will end up in the main packages at some point.
• There's some random stuff in there like steal_service_handle that I just haven't moved to its own thing yet, that can be ignored. That probably merits its own discussion at another time about whether ctru-rs/ctru-sys should include wrappers for Luma3DS-exclusive features.

[Meziu]

I honestly like the attempt to standardise the IPC interface in Rust. However, it’s hard for me to understand what the main goal of something like this would be.

In particular, what is meant to be “safe” here? The interface is written to be generic, yet in doing so there are no checks for what the IPC calls actually do (memory safety isn’t enough to make the API foolproof) . I’m sure some tinkering would prove the possibility of passing values “safely” into these functions yet cause abnormal behaviour, like by wrongly modifying data that could even crash the program.

Since I started re-writing and porting the current version of ctru-rs I’ve imposed on the project the ideal of a safe and unbreakable API (we’re far from that, but that’s the goal). This is why we make many high level checks, yet make unsafe calls all throughout the crate. By knowing the type of call to be made, and the context in which it is made, you don’t need to wrap the whole IPC interface, since the single call you need will be safely used regardless.

Again, it’s an interesting project, and it could make some new work easier (e.g. writing currently unimplemented services). I just don’t find it “safe enough” on its own to warrant usage. I would rather have to handle these system-level (and sometimes kernel-level) processes in C or in standard unsafe code.

This is only my extremely personal opinion, and I’d like to hear more from @rust3ds/active. The effort you’ve put into writing such an extensive wrapper for IPC is admirable. Experimenting and researching is very important here. Thank you for your work 😄

[DeltaF1]

In particular, what is meant to be “safe” here?

I don't really understand the question, sorry. I think you are asking how I can prove that all uses of this are safe? I'm not trying to create a generic safe interface, send_struct and send_cmd are very unsafe still. It's still the job of the people writing the safe wrappers to ensure that they are using the IPC call correctly (according to the interface laid out by the 3dbrew wiki/reverse engineering), just like when you write wrappers around libctru methods. The only real safety this adds is using borrow-checked references to construct the translate parameters and the static buffers for receiving data (and I have some checks to make sure that various sizes are correct/aren't going to overflow the command buffer but I'm not done that part yet). The point is to make writing those wrappers much easier/faster/less boilerplate and to remove possible sources of error like accidentally reading/writing the wrong spot in the command buffer.

It would be an interesting task to try to write a generic safe IPC interface but I think that would be very limited.

e.g. writing currently unimplemented services

This is the use case I had in mind. I wanted to port https://github.com/PabloMK7/ctr-led-brary but libctru doesn't wrap https://3dbrew.org/wiki/PTMSYSM:SetInfoLEDPattern. So I wrote send_struct and that takes care of all of the boilerplate details of writing to the command buffer and checking error codes etc. For calls that only have normal parameters I find it a lot faster to define two structs than to manually write to the ipc buf. (I also have a dream of scraping+parsing 3dbrew to make the request/response tables more machine-readable and make this process even easier but that's a whole other project)