search

rust3ds / ctru-rs

Rust wrapper for libctru
https://rust3ds.github.io/ctru-rs/
Other
122 stars 18 forks source link

Add SVC service wrapper #67

Closed SteveCookTU closed 2 years ago

SteveCookTU commented 2 years ago

This is a large PR which wraps the SVC service of ctru. Minimal documentation is here but there is at least some for a decent understanding.

This is a slightly major/important module for creating services or applications on the 3DS. It allows for proper communication between services along with synchronizing them through SVC calls as seen in the example of #65.

There are also 2 extra functions not given in libctru. One is Luma3DS only (which I may recommend removing only because Luma may be the custom OS of choice but it's not the only one). The other is to "steal" services as some have a restriction on how many handles can be owned at a time. I am unsure if this is just undocumented on libctru or is luma only as well.

Meziu commented 2 years ago

Honestly this doesn’t look like something we may want to expose to the user, ever. This is the crucible of non-safety and low level access to the system. We may want to think about something like this for internal use only (though at that point it’d be better to just use the C functions when needed), but there is just no way to make it have sense in other circumstances.

SteveCookTU commented 2 years ago

The problem I see with not providing this to the user is that we cut off the capabilities of what could be created with the library. Background services or "sysmodules" wouldn't be possible and other advanced techniques that many existing applications use such as PKSM.

Meziu commented 2 years ago

The problem I see with not providing this to the user is that we cut off the capabilities of what could be created with the library. Background services or "sysmodules" wouldn't be possible and other advanced techniques that many existing applications use such as PKSM.

If the user is looking into the development of “sysmodules” they shouldn’t be trying to use a safe wrapper around libctru. This stuff is so low level and out of our scope (which mainly targets userland apps) that I don’t see the point in adding it. Why would we go out of our way to build an unsafe layer which is probably not good enough in the scope of a thin system module? They should (and probably will) just use ctru-sys instead.

For any services which have functionality requiring the use of svc we can provide basic functionality which ensures safety via very strong and explicit code measures (like having to hold a struct for the whole duration of the process to ensure the service exists).

I’m sorry to have asked you about this PR, as I wasn’t aware of the true implications of this set of functions. This is simply not what ctru-rs is meant to be doing.

SteveCookTU commented 2 years ago

I’m sorry to have asked you about this PR, as I wasn’t aware of the true implications of this set of functions. This is simply not what ctru-rs is meant to be doing.

No worries! This helps me understand the extent ctru-rs will be. The only things I might say are truly unsafe about SVC are the memory mapping functions otherwise nothing else would cause undefined behavior unless there are bugs within the OS of the system. Anything that fails just leads to a runtime error but shouldn't be causing any issues within the system itself. What keeps everything safe is guaranteeing the handles are closed which the Drop implementation would provide.

I am no expert on this personally but this is from an explanation I got from others who have done a bit of work on the 3DS

Meziu commented 2 years ago

The only things I might say are truly unsafe about SVC are the memory mapping functions otherwise nothing else would cause undefined behaviour unless there are bugs within the OS of the system. Anything that fails just leads to a runtime error but shouldn't be causing any issues within the system itself. What keeps everything safe is guaranteeing the handles are closed which the Drop implementation would provide.

The problems here isn’t really with memory safety (which is also a risk in any case), but more with breaking the user contract. This effectively is a way to avoid the mutability checks imposed by Rust’s compiler. Having this “shortcut” and access to system administration basically erases every way to keep track of the changes within the application. This type of control is useful, but only in an unsafe environment (and at that point, why make an API if the whole thing has to be unsafe either way).

What I want you to know is that unsafe in ctru-rs doesn’t have to be correlated to segmentation faults or memory management, but even just an “unsupervised” way to control the program. Hope this clears up your doubts.

AzureMarker commented 2 years ago

What keeps everything safe is guaranteeing the handles are closed which the Drop implementation would provide.

BTW, drop is not guaranteed to be called in all cases. Leaking memory is safe! :upside_down_face: https://doc.rust-lang.org/nomicon/leaking.html

SteveCookTU commented 2 years ago

I understand now the usage for the library, definitely cleared things up. That being said I'm going to go ahead and delete the branch! Don't think it aligns with the library's goal