[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GSoC 2017] Work done so far

From: Joan Lledó
Subject: Re: [GSoC 2017] Work done so far
Date: Tue, 6 Jun 2017 21:41:14 +0200

2017-06-06 19:23 GMT+02:00 Justus Winter <justus@gnupg.org>:
> Hi :)
> Joan Lledó <joanlluislledo@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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]