-
Notifications
You must be signed in to change notification settings - Fork 92
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
ipv6 support #78
Comments
PSL1GHT just forwards socket calls to the system network SPRX (part of the PS3 firmware). If IPv6 does not work it is because Sony does not support it, not because ps3dev doesn't. If you need IPv6, it is supported by PS3 Linux. |
@zeldin That's fine if SPRX does it. Can we at least have some headers? I'll pass you the compile errors when I come back home. Also, building ioquake3 for PS3 Linux is a piece of cake. I wouldn't be filing this ticket if I was targetting Linux :) |
|
Ok, |
@zeldin I was able to verify that the net sprx does NOT support IPV6 with what you suggested. However, I understand @grepwood's pain here because I'm working on porting a library that uses some of these definitions because it supports both IPV4 and IPV6. So I think the ask here would be to add the missing definitions to the headers, and just make sure any time there are functions that take IPV6 options to return an error case and set errno appropriately. |
Fair enough, although if the library has an option to build it without IPv6 support you should use it because otherwise you'll just end up with dead code in the |
And regarding the And actually |
The correct way to handle this in the library/application is to |
Oh wow you're right, a lot of the IPV6 definitions in the netinet/in.h are optional. Which makes sense. So yeah as you're saying, since we know the PS3 doesn't natively support IPV6 there's no sense in adding those. |
@dee12452 @zeldin please check out https://github.com/ec-/Quake3e/issues/55 where the developer has made IPv6 completely optional. It still fails and crumbles in a billion places which pretty much means the existing stack is either largely incomplete or there is a magical header missing that would translate all of the standard IPv4 calls into |
@grepwood it's very likely just that the toolchain is incomplete. From just looking at it, you can kinda tell that the net stack was built on a "build it when you need it" mindset, so it's missing a lot of standard things even defined by POSIX standards. I too am not able to port some things I need for my project because of missing structs, macros, and functions which aren't necessarily dependent on IPV6 support. I would do more to help right now since I also need a lot of what you need, but I'm also brand new and still learning the stack. I'm guessing me being new probably warrants leeriness of me pushing code too. As for ps3dev/PSL1GHT#67, I actually started a POC over in newlib to move the net stack over to there, but it didn't take me long to realize that to do what is suggested would require a big change to how the toolchain is built in general. Right now gcc + newlib are installed without knowing anything about PSL1GHT, and since the net code (like socket.c, poll.c, inet funcs, etc.) depends on the net.h header definitions + the vsh exports in the libnet sprx, the toolchain build process is going to have to change significantly to support the suggested changes. Such a significant change that I wonder if it'd be worth it to make a new project for it entirely... |
@dee12452 All newlib code which needs to use sprx exports has to do it through callbacks in |
That beging said, it's unclear to me what the benefit of moving things over to newlib would be, since newlib does not currently contain any networking code that is not linux specific... |
@zeldin ah I see how that works now. And the callbacks are defined in newlib lv2/sys/syscallbacks.h. Good to know, I was definitely missing that piece. With that being said, I'm aware that moving the network code stack to newlib provides nothing for this particular issue, but instead just supports the ideas explained in the v3 RFC over in PSL1GHT. @grepwood do note that the RFC you're referring to won't necessarily add all the things that you and I need, it's essentially just a large cleanup task with what's currently implemented in PSL1GHT. The things you're asking for here need to be added to the headers whether someone moves them to newlib or not. |
Some applications require IPv6 support, like ioquake3. Can we please have ipv6 support in this toolchain?
The text was updated successfully, but these errors were encountered: