[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-devel] API change: restructuring ipv4/ipv6 integration (task #
Re: [lwip-devel] API change: restructuring ipv4/ipv6 integration (task #12722)
Fri, 10 Apr 2015 10:09:31 -0600
Holy mackerel Batman!
I'll be testing this next week.
I'll also look into task #13480 (lwIP as IPv6 only stack), but as a
potential user of IPv6-only I'm not too concerned about the few extra
bytes that basic IPv4 would add...
Date: Thu, 09 Apr 2015 22:19:53 +0200
From: "address@hidden" <address@hidden>
To: lwip-devel <address@hidden>
Subject: [lwip-devel] API change: restructuring ipv4/ipv6 integration
Content-Type: text/plain; charset=windows-1252; format=flowed
for those not reading lwip-users:
I just wanted to warn you I'm going to push a rather big change
regarding ipv4/ipv6 integration where the old 'ip_addr_t' will be
renamed to ip4_addr_t and ip_addr_t changed to replace ipX_addr_t,
including a version information. This ensures ipv4 and ipv6 addresses
are handled equal (more or less).
This results in an API change, which should hopefully not be noticed
ipv4-only users (LWIP_IPV6==0). In case it does change anything,
This is in preparation for the 1.5.0 release, but I expect more
in this area after possibly discussing this further on lwip-devel, so
the API might change again in the next weeks or so. So unless you
want to follow development, I suggest to not pull master tip unless
have sorted this out.
This mainly means that the tcp/udp/raw API uses dual-version IP
addresses everywhere and most of the IPv6-specific functions/defines
I'm just pushing this now to get forward on 1.5.0, but please feel
to share your critics here!
I hope that there are no compiler errors left, but given the amount of
possible define-combinations and function-like-defines I might not all
use, chances are I missed some, so please share them here if you find
The next step (which I already started with that commit) is task
(lwIP as IPv6 only stack).