Re: [lwip-devel] Changes in lwip to make it work in the Hurd

[Joan Lledó]

Hi Simon,

>> 1.- We're using an external DHCP client that needs to send UDP packets
>> from 0.0.0.0 to 255.255.255.255 for DHCPDISCOVER messages. I made two
>> changes:
>
>
> Without really checking into it: what's wrong with the way the internal DHCP
> client sends messages? Can't you copy its behaviour?
> Maybe I didn't get your problem. The interface should already have its
> address set to 0.0.0.0 at that point, shouldn't it? Maybe that's what you're
> doing wrong...

The ifupdown system sets the address to IPADDR_NONE before trying to
send the DHCPDISCOVER. But I've reviewed it again and I think I can
solve this problem using the routing hook.

>> 2.- We use two different sys_arch_sem_wait() functions in our
>> sys_arch.c.
>
>
> What's the question here?

There's no question, actually, I thought it could be interesting to
share the case.

>
>> 3.- The inet server may be reconfigured in runtime, that means
>> removing and adding new interfaces while the tcpip thread is running.
>
> I have recently changed the way error callbacks are handled for TCP sockets.
> Also, your base version does not have the multithreading socket changes
> included (which are also not that old). Please check again with a more
> recent version of lwIP.

OK, I'll try with newer versions.

>>
>> 4.- We received a patch[5] that implements lwip_poll() in sockets.c.
>
>
> Provided the license allows it, I'd be open to integrate it. Please upload
> it to our patch tracker.

I'll send it as soon as possible.

>> 5.- Nothing important, but in my Ethernet driver I had to change the
>> exit condition in output and input loops, because the default
>> example[6] exits when q->next == 0, and should be when q->tot_len ==
>> q->len.
>
>
> The default example is *not* located at github.com, but at
> http://git.savannah.nongnu.org :-)
> Also, for the input loop, this is perfectly OK as the pbuf is allocated just
> before!
> For the output loop, we could discuss which version is better. However,
> pbufs chains passed to an output function always only get one packet, so in
> real life, both versions are equally good...

OK