Merged from main.
diff --git a/doc/contrib.txt b/doc/contrib.txt
index 252724a..7c46561 100644
--- a/doc/contrib.txt
+++ b/doc/contrib.txt
@@ -1,4 +1,9 @@
-How to contribute to lwIP
+1 Introduction
+
+This document describes some guidelines for people participating
+in lwIP development.
+
+2 How to contribute to lwIP
Here is a short list of suggestions to anybody working with lwIP and
trying to contribute bugreports, fixes, enhancements, platform ports etc.
@@ -6,53 +11,53 @@
to fixes or questions might often come late. Hopefully the bug and patch tracking
features of Savannah help us not lose users' input.
-Source code style:
+2.1 Source code style:
-- do not use tabs.
-- indentation is two spaces per level.
-- end debug messages with a trailing newline (\n).
-- one space between keyword and opening bracket.
-- no space between function and opening bracket.
-- one space and no newline before opening curly braces of a block.
-- spaces surrounding assignment and comparisons.
-- use current source code style as further reference.
+1. do not use tabs.
+2. identation is two spaces per level.
+3. end debug messages with a trailing newline (\n).
+4. one space between keyword and opening bracket.
+5. no space between function and opening bracket.
+6. one space and no newline before opening curly braces of a block.
+7. spaces surrounding assignment and comparisons.
+8. use current source code style as further reference.
-Source code documentation style:
+2.2 Source code documentation style:
-- JavaDoc compliant and Doxygen compatible.
-- Function documentation above functions in .c files, not .h files.
- (This forces you to synchronize documentation and behaviour.)
-- Use current documentation style as further reference.
+1. JavaDoc compliant and Doxygen compatible.
+2. Function documentation above functions in .c files, not .h files.
+ (This forces you to synchronize documentation and behaviour.)
+3. Use current documentation style as further reference.
-Bug reports and patches:
+2.3 Bug reports and patches:
-- Make sure you are reporting bugs or send patches against the latest
- sources. (From the latest release and/or the current CVS sources.)
-- If you think you found a bug make sure it's not already filed in the
- bugtracker at Savannah.
-- 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
- 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.
-- 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.
-- 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.
-- 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.
+1. Make sure you are reporting bugs or send patches against the latest
+ sources. (From the latest release and/or the current CVS 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
+ 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
+ if it's not to the point and long :) so the chances for it to be applied are greater.
-For platform porters:
+2.4 Platform porters:
-- If you've 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 to post an url to a tarball or zip from which it can be imported
-to the contrib CVS module. Then you get CVS access and have to maintain your port :)
+1. If you've 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 to post an url to a tarball or zip from which it can be imported
+ to the contrib CVS module. Then you get CVS access and have to maintain your port :)
[1] - lwIP CVS should not be just a place to keep your port so you don't have to set up your own CVS :)
Especially welcome are ports to common enough OS/hardware that others can have access too.
diff --git a/src/core/pbuf.c b/src/core/pbuf.c
index 41da523..cc9019c 100644
--- a/src/core/pbuf.c
+++ b/src/core/pbuf.c
@@ -13,11 +13,18 @@
* Multiple packets may be queued, also using this singly linked list.
* This is called a "packet queue". So, a packet queue consists of one
* or more pbuf chains, each of which consist of one or more pbufs.
+ * The differences between a pbuf chain and a packet queue are very
+ * subtle. Currently, queues are only supported in a limited section
+ * of lwIP, this is the etharp queueing code. Outside of this section
+ * no packet queues are supported as of yet.
*
* The last pbuf of a packet has a ->tot_len field that equals the
* ->len field. It can be found by traversing the list. If the last
* pbuf of a packet has a ->next field other than NULL, more packets
* are on the queue.
+ *
+ * Therefore, looping through a pbuf of a single packet, has an
+ * loop end condition (tot_len == p->len), NOT (next == NULL).
*/
/*
@@ -206,6 +213,7 @@
struct pbuf *p, *q, *r;
u16_t offset;
s32_t rem_len; /* remaining length */
+ DEBUGF(PBUF_DEBUG | DBG_TRACE | 3, ("pbuf_alloc(length=%u)\n", length));
/* determine header offset */
offset = 0;
@@ -233,6 +241,7 @@
case PBUF_POOL:
/* allocate head of pbuf chain into p */
p = pbuf_pool_alloc();
+ DEBUGF(PBUF_DEBUG | DBG_TRACE | 3, ("pbuf_alloc: allocated pbuf %p\n", p));
if (p == NULL) {
#ifdef PBUF_STATS
++lwip_stats.pbuf.err;
@@ -291,7 +300,7 @@
r = q;
}
/* end of chain */
- r->next = NULL;
+ //r->next = NULL;
break;
case PBUF_RAM:
@@ -331,6 +340,7 @@
}
/* set reference count */
p->ref = 1;
+ DEBUGF(PBUF_DEBUG | DBG_TRACE | 3, ("pbuf_alloc(length=%u) == %p\n", length, (void *)p));
return p;
}
@@ -534,6 +544,7 @@
DEBUGF(PBUF_DEBUG | DBG_TRACE | 2, ("pbuf_free(p == NULL) was called.\n"));
return 0;
}
+ DEBUGF(PBUF_DEBUG | DBG_TRACE | 3, ("pbuf_free(%p)\n", (void *)p));
PERF_START;
@@ -557,6 +568,7 @@
if (p->ref == 0) {
/* remember next pbuf in chain for next iteration */
q = p->next;
+ DEBUGF( PBUF_DEBUG | 2, ("pbuf_free: deallocating %p\n", (void *)p));
/* is this a pbuf from the pool? */
if (p->flags == PBUF_FLAG_POOL) {
p->len = p->tot_len = PBUF_POOL_BUFSIZE;
@@ -575,6 +587,7 @@
/* p->ref > 0, this pbuf is still referenced to */
/* (and so the remaining pbufs in chain as well) */
} else {
+ DEBUGF( PBUF_DEBUG | 2, ("pbuf_free: %p has ref %u, ending here.\n", (void *)p, p->ref));
/* stop walking through chain */
p = NULL;
}
@@ -661,7 +674,7 @@
p->next = t;
/* t is now referenced to one more time */
pbuf_ref(t);
- DEBUGF(PBUF_DEBUG | DBG_FRESH | 2, ("pbuf_chain: referencing tail %p\n", (void *) t));
+ DEBUGF(PBUF_DEBUG | DBG_FRESH | 2, ("pbuf_chain: %p references %p\n", (void *)p, (void *)t));
}
/* For packet queueing. Note that queued packets must be dequeued first
@@ -869,6 +882,7 @@
/* q is no longer referenced by p, free it */
DEBUGF(PBUF_DEBUG | DBG_STATE, ("pbuf_dechain: unreferencing %p\n", (void *) q));
tail_gone = pbuf_free(q);
+ if (tail_gone > 0) DEBUGF(PBUF_DEBUG | DBG_STATE, ("pbuf_dechain: deallocated %p (as it is no longer referenced)\n", (void *) q));
/* return remaining tail or NULL if deallocated */
}
/* assert tot_len invariant: (p->tot_len == p->len + (p->next? p->next->tot_len: 0) */
