Feedback on the proposed debug/logging system:
1. If you want to be compatible with Linux syslog, you could define the
levels the same: LOG_EMERG=0; LOG_ALERT=1; LOG_CRIT=2; LOG_ERR=3;
LOG_WARNING=4; LOG_NOTICE=5; LOG_INFO=6; LOG_DEBUG=7. That would
make it easier if someone wanted to connect it to syslog at some point.
2. Additional (deeper) levels of debug information are nice because you
might include a lot of information at LOG_DEBUG level during
development but then want to turn it off when things are working,
without removing or commenting-out the statements, in case they're
needed again some day. e.g. LOG_DEBUG_2=8; LOG_DEBUG_3=9.
3. There's a decision built in here: is the overall log level a
statically-defined value or a variable? The former is less
flexible, but it does allow you to leave the LOGGER/LOGDBG
statements always there and rely on the optimizer to eliminate dead
code above the current log level. For instance:
#if CMAKE_BUILD_TYPE == Debug
#define CURRENT_LOG_LEVEL LOG_INFO
#else
#define CURRENT_LOG_LEVEL LOG_ERR
#endif
#define LOGGER(level, channel, msg, ...) if (level <=
CURRENT_LOG_LEVEL) { log_msg(...); }
An optimizing compiler should throw the code away any time the
overall level is too low (assuming "level" is a macro-constant).
You don't need separate macros that way -- a release build should
naturally toss all the LOGGER(LOG_INFO,....) statements; a debug
build would leave them in. (For clarity, I'm leaving out macro
niceties such as extra parentheses and "do {xxx} while(0)".)
4. In such a case, it'd be nice to make the CURRENT_LOG_LEVEL something
you can set as a Cmake macro that becomes a "-Dxxx" option:
#ifndef CURRENT_LOG_LEVEL
#define CURRENT_LOG_LEVEL something
#endif
Then you can build a fully-optimized build with full logging, if you
like. Just set it to a higher value than normal.
5. It'd be nice to have a way to turn on and off timestamps on the log
messages. Either a log_with_timestamps(bool) entrypoint or perhaps
a separate LOGGER_WITH_TIMESTAMP() call?
6. It'd be nice to be able to tell the logging system to send its
messages to stderr, stdout, or an arbitrary fildes. Like a logging
subscription service. Then it's just a small patch to add a new
fildes and use it for a custom output-handling system.
7. A flush function is nice in case you're working with code that can
crash the system.
8. The idea of popping up a dialog box is tricky:
1. Such a system should really handle localization of the messages.
2. The dialog style may not match dialogs everywhere else on the
system. I would lean here toward an architecture where user
interaction is a pluggable module. The default version might
just interact at the stderr/stdout level. But different
vendors could plug in their own back-end for Qt, Gnome, Mac,
Windows, whatever. Such a system would also handle things like
asking for a password, verifying a certificate, etc. This is a
much bigger job than just the logging question.
3. So... I'd just kick that can down the road for now. If it's
easy to output the information to a file, people can write their
own code to deal with that file. For now.
Regards,
Daryl Poe
HP Thin Clients
On 12/5/2012 12:17 PM, Marc-André Moreau wrote:
> <clip>
> As for using the mailing list, yes, it ought to be used. Another discussion
> for which I would really appreciate some help is the design of a better
> debug/log system. The current one is severely limited, and there is a large
> number of requirements which an ideal debug/log system would need to meet.
> Since this affects everyone and pretty much all the code, I need your input
> on this. We're currently collecting information on this wiki page:
> https://github.com/FreeRDP/FreeRDP/wiki/Debug-System
>
> I repeat, I need input on this. I'd rather have it before than after it's
> changed. It's a tough design question, and I'd rather make the change to a
> well designed debug system once than switch to something partially proper
> and still need to change it a lot later on.
>
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Freerdp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freerdp-devel
