lwip-members
[Top][All Lists]
Advanced

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

Re: [lwip-members] new debugging features in CVS


From: Leon Woestenberg
Subject: Re: [lwip-members] new debugging features in CVS
Date: Fri, 21 Feb 2003 16:18:51 +0100

Hello Jani,

your ideas look fine.

Also bear in mind that most *.c files must be adapted to
#include "lwip/opts.h" as a first include (which is logical,
since it configures lwIP).

Also, #include "debug.h" or "lwipopts.h" can be removed
from the *.c files then.

Are you willing to perform this change Jani? I will not
be able to work on lwIP the next two weeks.

Regards, Leon.

> After some more thought and trial here's what I propose:
>
> 1)Have everything configurable set to defaults in lwip/opt.h
> only put defines which appear in lwip core not DEBUG_TAPIF,DEBUG_DEMO etc.
> 2)debug.h should contain the flags and diagnostic definitions but NO
> user-overridable settings (diags are overwritten by platform that's OK)
> 3)A project should compile with empty lwipopts.h
>
> lwip/opt.h looks like
>
> #include "lwip/debug.h" //this provides the dbg flags to lwipopts
> #include "lwipopts.h"  // anything the user wants to redefine
>
> //every default here:
>
> #ifndef LWIP_FOO
> #define LWIP_FOO DEFOOLT
> #endif
> ...
>
>
> Right now I see no drawback to this scheme (otherwise I wouldn't have
posted ;)
> but the benefits are smaller & easier to manage lwipopts and lwip files
can
> now include opt.h and not debug since that is included anyway.
>
> what do you think?
>
>
>
> > Hello Jani,
> > > But does this mean lwipopts.h must define every modules' debug flag?
> > > Can't the behaviour of old debug.h includes lwipopts.h be preserved
> > > where debug.h defines every previously undefined (in lwipopts) macro.
> > >
> > Yes, that would be perfect.
> >
> > The problem is that lwipopts.h now depends on debug.h (for the debug
flags)
> > and not vice versa.
> >
> > Fixing this would mean debug.h including lwipopts.h only after the debug
> > types
> > have been defined.
> >
> > Of course, any other nicer approach would be more welcome.
> >
> > As a sidenote, before the new finer grained debug scheme starts to pay,
> > additional debug type flag and level must be given to DEBUGF statements.
> > For example DEBUGF(UDP_DEBUG | DBG_TRACE | 2, "some flow following debug
> > statement of 2");
> >
> > Leon.
> >
> >
> >
> > _______________________________________________
> > lwip-members mailing list
> > address@hidden
> > http://mail.nongnu.org/mailman/listinfo/lwip-members
>
>
> _______________________________________________
> lwip-members mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/lwip-members
>





reply via email to

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