|
From: | address@hidden |
Subject: | Re: [lwip-devel] Changes in lwip to make it work in the Hurd |
Date: | Mon, 21 Aug 2017 21:36:10 +0200 |
User-agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
Joan Lledó wrote:
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...
2.- We use two different sys_arch_sem_wait() functions in our sys_arch.c.
What's the question here?
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.
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.
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...
Cheers, Simon
[Prev in Thread] | Current Thread | [Next in Thread] |