[Top][All Lists]

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

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

From: Joan Lledó
Subject: Re: [lwip-devel] Changes in lwip to make it work in the Hurd
Date: Tue, 29 Aug 2017 10:47:30 +0200

Hi Simon,

>> 1.- We're using an external DHCP client that needs to send UDP packets
>> from to 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 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...


reply via email to

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