New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Network socket changes #136
Conversation
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good, all up! I'm not convinced about having all the socket headers in include/
and include/sys/
. Did you write them yourself? Might be a little more maintainable to nick 'em from BSD, like what libnx does (they also bury it all under external/
). Just minor nitpicks, though!
@@ -2,11 +2,13 @@ void __init_wut_malloc(); | |||
void __init_wut_newlib(); | |||
extern void __init_wut_stdcpp() __attribute__((weak)); | |||
void __init_wut_devoptab(); | |||
void __init_wut_socket(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These could potentially be weak functions? Could be one way around the AC issue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitively an option; waiting for more comments on this
Theorically this shouldn't happen
Thanks for the suggestions! 👍 Not sure about the bsd socket headers; while they are what libnx uses, other platforms, such as libctru, also provide their own headers. They work very well for the Switch since the os provides an almost complete bsd sockets implementation, but on the wiiu many of the additional symbols provided by those headers are not available/wouldn't have any effect, so they might result in unnecessary clutter. Also as nintendo won't update nsysnet anymore, we probably wouldn't really need that much maintainance for the headers after they are working |
Just realized we might have one additional issue related to these changes: libcurl allows applications to interact with the network sockets used by the library, which for nintendo's libcurl port would be coming from the nsysnet library rather than newlib. |
This is a fair point! Just wanted to make sure we're following standards here. POSIX all the way! Maybe there's some kind of test suite we could run these headers against? Maybe I'm just nervous, I dunno.
I agree that a new libcurl is a better long-term solution, but mbedtls is kinda annoying (I've tried messing with it before, see yawut/mbedtls) so colour me unconvinced we'll be able to pull it off quickly. As a shorter-term solution, wutsocket could rplwrap the relevant libcurl functions too? I'd imagine the actual code would be super trivial, just looking for the conditions where libcurl gives an fd and passing it through the appropriate lookup tables. |
Yes both some curl methods and also NSSLCreateConnection takes a socket file descriptor. |
Yeah. Any progress on updating the |
I'm going to have a go at finishing this PR. |
I added a few more functions in my fork here: https://github.com/GaryOderNichts/wut/tree/wutsocket |
Good to know. I'm first going to try implementing the weak linking mechanism suggested in one of the conversations above, though. In the mean time, can you PR some of your other fixes? I saw a gettod fix that is unrelated to socket stuff in your branch. |
Yeah, will do. |
Opening this PR to keep track of wutsocket changes/issues/suggestions.
The wutsocket library provides standard network headers and a devoptab for the nsysnet socket library.
Status:
Potential issues:
The wutsocket library is currently initialized from wutcrt, and internally handles nn_ac and the nsysnet socket library initialization. This is not ideal as some applications might not need to use the network, and the AC initialization might require some time (this last issue can partially be resolved using async initialization).
Also the nsysnet retrocompatibility layer, while present, could potentially cause issues with a limited number of applications (for example apps manually defining nsysnet error codes, which won't match the returned errno codes).
Any suggestion regarding those or other possible issues is welcome