Am Montag 15 März 2010 07:38:45 schrieb Martin Paljak: > For example, in the > probably most common scenario (inside a function, after checking some > return code) the essence of the debug call - the message itself - starts > on column 53 (with tab size 8).
yes, small messages fit on the same line, longer texts start on a new line. > With 3320 calls to sc_debug and friends > this would mean extra ~68 kilobytes of raw source. code size isn't an issue here I think. > IMHO it is also important to have a difference in logging (which is usually > done in long-running applications) and piping debug information to > somewhere. OpenSC seems to fall into the latter category. As the name > implies, sc_debug deals with *debugging* not logging. sc_debug is a #define for sc_do_log() so the name doesn't help here. > Debugging should normally be turned off as things should work as expected. that is now the case. we used to have some mechanic to turn logging/debugging on when things go wrong (with a heuristic that failed quite often), but that code was remove a while ago. > If things fail, > people start to debug. It could be a flip switch or it could be a linear > value (like it currently is) to have progressively increasing verbosity. that is the goal. I posted the values (those enum constants): debug=0 -normal, no output. debug=1: only for tools (with -v parameter), makes the tool verbose, no change to libopensc/opensc-debug.so. debug=2,3,6,7 are the current magic values: some debugging, more debugging, and finally even debugging in the asn1 and card matching code (both quite useless, unless you debug an error related to that). > Instead of trying to categorize debug statements with code constants it > would be better to agree on some common level for common tasks and > document it and follow it. well I implemented the common tasks I know about: asn1 and card matching debug info only makes the log file large, but you never need it, unless the bug is in those subsystems. so debug value "3" is the one you will want for now. not sure why there is this split debug level 2/3, I only copied the old situation into new symbolic values. cleanups are welcome, I see no structure in the old debug level situation, but mostly chaos. > Encoding the common levels as wrapper functions or macros like > sc_debug1/SC_DEBUG1 would also be a solution (but not mandatory as there's > no need to keep the API stable) the big change was: now all debug functions take the level as argument, and check "ctx->debug >= level" themself. prior some did that, but not all, that was chaos. any further changes, like changing the constants I introduced, or new debug macros like the ones you mention, can be easily implemented on top of my changes with "sed". (70% of my work was dealing with the 3% special cases we had in the code, then later a few big sed changed the code to use the new API, and a manual cleanup on some parts of the code after that). the patch is quite big, and it will be hard to maintain. so if noone objects I will commit the changes now - at least to me it seems we can easily improve things on top of the patch, rather than tune the patch now before commiting it. if I'm wrong we can revert it later. Regards, Andreas _______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
