[olsr-dev] Re: Die "%m", die

[Andreas Tønnesen]

Bernd Petrovitsch wrote:
>>Sounds fair enough. But should the debug level be a "level" like it is
>>today, or rather a mask whare we can categorize the debug info better? The
> 
> 
> Do we actually have categories that make sense?

 From a devs perspective I certainly think so. It might be interesting 
debugging just the scheduler, NIC changes, neighor set changes,
packet reception etc. without having all the other debug output
automatically applied. The dager is that you might end up with one flag
for every smallest functionallity.
But from a "system" point of view I don't know how useful this is and
it might be cumbersome for end-users to use. But then again one could
create predefined debug levels from these groups which woul create an
easy interface for users...
might be an overkill though :-)

> That's the question. I wouldn't forget (or ignore) simplicity - both for
> the admin/user choosing a debug value/mask and the developer which has
> to decide on the level and/or bits in th mask for every single message.

Yepp.

> To answer that question: IMHO "no". It is quite simple. And I usually in
> my code, the log levels are to the syslog levels. On the first run, the
> values are more or less random since they are development driven, but
> once the code stabilized the messages are marked more for "maintenance"
> use.
> I would make one "log level" identical to syslog levels and these would
> be compile- (one value or it becomes cumbersome) and run-time tunable -
> perhaps different for "fprintf" and "syslog" - (let alone via syslog
> config).
> Categories (which do we actually have if we have them?) are ortogonal to
> this.

Yes, simplicity is a good thing. As for categories I'd say we already
have two of them implemented in the -dispin and -dispout command-line
options.
 From the top of my head others could be:
*Link set changes
*Neighbor set changes
*MID set
*HNA set
*TC set
*route calculation
*scheduler operation
*NIC changes polling

Then we could easily define the debuglevels as masks of these.
I think it is a nice thing to be able to explicitly activate debug for
stuff that currently is only available in the higher debug levels
without getting everything else with it as -d 9 does now.
But these are just some basic ideas here... I'm definetly not saying
that this is the way it should be done! It all comes down to how
much complexity we want to add in this and KISS has proven to be the
best way most of the time :-)

$0.05 from a dark&&frozen Norway

- Andreas