I just finished getting my program to compile with libogc's network.h (although I haven't tested the functionality just yet). I had to hack a few things in my program to get it to compile. It would be nice if network.h had a closer API to POSIX so I don't need extra #ifdef's.
1. Why the net_ prefix on all the functions? I had to do
#define send net_send
#define accept net_accept
...
2. I had to provide dummy functions for getsockname, gethostbyaddr, getsockopt. The last one seems like an omission from libogc since net_setsockopt exists.
3. Not a huge deal but it would be nice to provide the same headers as linux: net/select.h, netinet/in.h, netinet/tcp.h, arpa/inet.h.
network.h
-
- Site Admin
- Posts: 1862
- Joined: Tue Aug 09, 2005 3:21 am
- Location: UK
- Contact:
Re: network.h
The net_ prefix originally came from the lwip port we did for gamecube and the wii updates were just made compatible with that.
I'd actually really, really like to provide some standard headers and use standard function names instead, we did that for dswifi and it makes porting things a lot easier.
On IRC you mentioned the possibility of supplying patches which would be much appreciated if you have the time to look into it.
I'm not a big fan of using defines to change function names tbh, what might be better is to use function attributes to create the standard functions as aliases for the net_ prefixed functions. The standard headers can just be added to the gc folder in SVN although I'm not 100% sure about close offhand. For dswifi I had to replace this with closesocket because it's not hooked into the open/close functions from fcntl.h.
I'd actually really, really like to provide some standard headers and use standard function names instead, we did that for dswifi and it makes porting things a lot easier.
On IRC you mentioned the possibility of supplying patches which would be much appreciated if you have the time to look into it.
I'm not a big fan of using defines to change function names tbh, what might be better is to use function attributes to create the standard functions as aliases for the net_ prefixed functions. The standard headers can just be added to the gc folder in SVN although I'm not 100% sure about close offhand. For dswifi I had to replace this with closesocket because it's not hooked into the open/close functions from fcntl.h.
Re: network.h
I don't see how that would work. The standard functions known as close, read, write, ioctl, fcntl, select etc. are all defined to operate on file descriptors which are not the same thing as libogc's network sockets. What happens if someone uses write() in one function to output to a file and tries to use it in another function to write to a socket? Or even worse, combines FDs from different sources in a call to select() (or the wii equivalent, poll()) ?
(btw, net_poll() is broken on wii. IOS uses POLLOUT=0x0008, POLLERR=0x0020, POLLHUP=0x0040, POLLNVAL=0x0080.)
Seems like it would make more sense to rewrite the network code so sockets actually behave like FDs i.e. give them their own devoptab and (finally!) add an ioctl function pointer member to devoptab_t.
(btw, net_poll() is broken on wii. IOS uses POLLOUT=0x0008, POLLERR=0x0020, POLLHUP=0x0040, POLLNVAL=0x0080.)
Seems like it would make more sense to rewrite the network code so sockets actually behave like FDs i.e. give them their own devoptab and (finally!) add an ioctl function pointer member to devoptab_t.
-
- Site Admin
- Posts: 1862
- Joined: Tue Aug 09, 2005 3:21 am
- Location: UK
- Contact:
Re: network.h
I didn't particularly mean close, read, write, ioctl, fcntl, select etc so much as send, sendto, sendmsg, recv, recvmsg, recvfrom, socket etc.
At some point I guess we're crossing the line from a posix like API on baremetal to something that resembles an OS in it's own right. The question is do we want to go that far?
I'd certainly like to see things progress to the point where we can use configure to build cyassl or curl.
At some point I guess we're crossing the line from a posix like API on baremetal to something that resembles an OS in it's own right. The question is do we want to go that far?
I'd certainly like to see things progress to the point where we can use configure to build cyassl or curl.
Who is online
Users browsing this forum: No registered users and 3 guests