2017-06-06 19:23 GMT+02:00 Justus Winter <jus...@gnupg.org>: > Hi :) > > Joan Lledó <joanlluisll...@gmail.com> writes: > >> It's useful to make a review of the work done in the last months and >> list some of the problems arisen during this period. > > Thank you for your nice writeups, they are appreciated :) > >> The process of writing the sockets and I/O operations have been quite >> straightforward. Most of actions performed by pfinet's operations are >> already implemented by LwIP, this includes managing the state of the >> sockets and concurrency, so many operations in the LwIP translator >> only check for RPC credentials, call the proper function in LwIP's >> sockets API and return errno. Connect[1] operation is a good example. >> As you may see, some operations like recv and connect itself have >> needed some additional changes to meet the requirements of Glibc, but >> in general, problems have come later. > > That is how it should be. Consider writing a function that maps LwIP > error codes to the appropriate Hurd ones if possible.
There's no need, LwIP already provides a function to do so and is returning our errnos. I had to make minor changes[1] in the stack to support our 32-bit errno format. It is also using our sys/socket.h, but that patch[2] is still not accepted. > >> One of the major issues I had was related with the get_openmodes[2] >> I/O operation. The implementation in pfinet[3] returns O_WRITE if our >> local socket hasn't sent the FIN message, and O_READ if the peer >> hasn't sent it. The operation also returns O_NONBLOCK if that flag is >> enabled on the local socket. In LwIP, only the O_NONBLOCK flag was >> supported by lwip_fcntl()[4], so I had to make some changes in that >> function in order to support the other two flags. I wrote a patch[5] >> that was rejected as it was based on some misconceptions and wasn't >> polished, but finally managed to fix it and was accepted to be part of >> the next LwIP release, 2.0.3. > > Congratulations :) > >> And that's all until today. From the list of tasks I included in my >> proposal[6], the following are still pending: >> >> - Add support for IPv6 >> - Implement other interfaces' operations if needed. >> - Implement support for more than one Ethernet interface. >> - Add support for command-line parameters. >> - Add support for fsysopts. > > I'd suggest doing the last two first. That should be easy actually, > just lift the code from pfinet, and stub out what isn't straight forward > to do. Once we understand roughly the same flags, we can use lwip as a > drop-in replacement for pfinet and see where things break. Ok. I have a TODO list with some bugs I found and some extra features that would be nice to implement. I'll tidy it up and share it as soon as I can. > >> The prototype is working and is able to connect to the Internet. But >> when one tests it seriously many errors arise, so it's still far from >> being stable and there's still a lot to polish. > > I tried it and it worked fine. Thanks for your work so far :) > > > Cheers, > Justus -------- [1] https://savannah.nongnu.org/patch/?9262 [2] https://savannah.nongnu.org/patch/?9350
