Hello David,
there was an earlier RFC regarding debugging, before you joined the
CVS commit members. See here (or the extract below).
http://mail.nongnu.org/archive/html/lwip-members/2002-12/msg00000.html
One new issue that I have thought of since then:
Have a debug prefix (DBG_ or DEBUG_) instead of a _DEBUG postfix,
just like (all?) other lwIP defines.
I like the idea of dynamic enabling/disabling debugging. I think there are
enough reasons to rebuild the current debug module.
This a part of the original RFC:
----snippet start----
Besides introducing some debug severity levels, I would like to introduce
the
concept of debug message type.
The goals are to be able to
- switch certain types of debugging on or off.
- have a debug threshold so that the verbosity can be controlled.
I would to keep to current interface, just use some extra bits in the debug
byte :
(currently has values 0 or 1).
Types:
DBG_TRACE 0x80
DBG_STATE 0x40
DBG_FRESH 0x20
bit 0 indicates whether the debug message is enabled at all.
(to maintain backwards compatibility).
Levels 0-3 (in bits 1 and 2):
level 0 means lowest severity
level 3 means highest severity
DBG_TRACE allows one to follow the program flow
(i.e. there is exactly one DBG_TRACE statement per C block, so
that all branch decisions, function calls and loops can be traced.)
DBG_STATE allows one to keep track of the state of a module.
(like the contents of the ARP cache, or the linked list of the memory
allocator).
DBG_FRESH allows one to mark new code and extend debugging.
Examples:
DEBUGF(DBG_TRACE | DBG_DHCP, "dhcp_renew(): Renewing IP address lease.");
DEBUGF(DBG_TRACE | DBG_ETHARP, "etharp_ip_input(): Sending queued
packets.");
DEBUGF(DBG_STATE | DBG_ETHARP, "etharp table[i]: %u.%u.%u.%u -
%02x:%02x:%02x:%02x:%02x:%02x", ...);
DEBUGF(DBG_FRESH | DBG_STATE | DBG_ETHARP, "etharp table[i]: adding packet
%p to the queue.", ...);
----snippet end----
_______________________________________________
lwip-users mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/lwip-users