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: Jani Monoses
Subject: Re: [lwip-members] new debugging features in CVS
Date: Fri, 21 Feb 2003 18:44:02 +0200

Ok I'm about to commit changes which were discussed in this thread
and also the lowercasification of htons style functions.For little
endian they are in inet.c; platforms no longer need them defined (c16x is
from where I copied them)
I tagged the tree "before_debug_opt_merge" before commiting so
anybody having problems can chack that but that had lots of compile
issues anyway.

Jani.

> 
> 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
> >
> 
> 
> 
> _______________________________________________
> 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]