[TCPIP] Synchronize LWIP code to 2.2.0

- take code from STABLE-2_2_0_RELEASE commit on https://git.savannah.gnu.org/git/lwip.git
- remove lwip/contrib directory
- do required changes due to upgrade in
  * CMakeLists.txt
  * include/lwip/arch/cc.h
  * include/lwip/arch/sys_arch.h
  * include/lwip/lwipopts.h
  * include/tcpip.h
  * ip/CMakeLists.txt
  * ip/lwip_glue/lwip_glue.h
  * ip/lwip_glue/tcp.c
  * ip/transport/tcp/if.c
  * tcpip/icmp.c

CORE-13098
This commit is contained in:
Hervé Poussineau 2024-04-20 20:26:04 +02:00
parent bc94df7288
commit d6eebaa47a
449 changed files with 132870 additions and 38788 deletions

View file

@ -34,30 +34,25 @@ features of Savannah help us not lose users' input.
2.3 Bug reports and patches:
1. Make sure you are reporting bugs or send patches against the latest
sources. (From the latest release and/or the current CVS sources.)
sources. (From the latest release and/or the current Git sources.)
2. If you think you found a bug make sure it's not already filed in the
bugtracker at Savannah.
3. If you have a fix put the patch on Savannah. If it is a patch that affects
both core and arch specific stuff please separate them so that the core can
be applied separately while leaving the other patch 'open'. The prefered way
be applied separately while leaving the other patch 'open'. The preferred way
is to NOT touch archs you can't test and let maintainers take care of them.
This is a good way to see if they are used at all - the same goes for unix
netifs except tapif.
4. Do not file a bug and post a fix to it to the patch area. Either a bug report
or a patch will be enough.
If you correct an existing bug then attach the patch to the bug rather than creating a new entry in the patch area.
5. Trivial patches (compiler warning, indentation and spelling fixes or anything obvious which takes a line or two)
can go to the lwip-users list. This is still the fastest way of interaction and the list is not so crowded
as to allow for loss of fixes. Putting bugs on Savannah and subsequently closing them is too much an overhead
for reporting a compiler warning fix.
6. Patches should be specific to a single change or to related changes.Do not mix bugfixes with spelling and other
trivial fixes unless the bugfix is trivial too.Do not reorganize code and rename identifiers in the same patch you
change behaviour if not necessary.A patch is easier to read and understand if it's to the point and short than
5. Patches should be specific to a single change or to related changes. Do not mix bugfixes with spelling and other
trivial fixes unless the bugfix is trivial too. Do not reorganize code and rename identifiers in the same patch you
change behaviour if not necessary. A patch is easier to read and understand if it's to the point and short than
if it's not to the point and long :) so the chances for it to be applied are greater.
2.4 Platform porters:
1. If you have ported lwIP to a platform (an OS, a uC/processor or a combination of these) and
you think it could benefit others[1] you might want discuss this on the mailing list. You
can also ask for CVS access to submit and maintain your port in the contrib CVS module.
can also ask for Git access to submit and maintain your port in the lwIP/contrib subdir.