Messages in this thread |  | | Date | Mon, 27 Nov 2000 01:30:06 +0200 (GMT-2) | From | Elmer Joandi <> | Subject | Universal debug macros. |
| |
On Sun, 26 Nov 2000, Rogier Wolff wrote: > Sure it will slow the driver down a bit, because of all those bit-test > instructions in the driver. If it bothers you, you get to turn it > off. If you are capable of that, you are also capable enough to turn > it back on when neccesary.
Now if there would be simple _unified_ system for switching debug code on/off, it would be a real win. That recompilation-capable enduser would not need much knowledge to go "General Setup" or newly created "Optimization" section and switch debugging off/on for _all_ network drivers or ide drivers for example.
> The debug asserts that trigger during normal operation are what make > the Linux kernel stable. Problems get spotted at an early > stage. Problems get fixed.
Yess
Lets say LDBG_* namespace, macros being in general form: LDBG_OPERATION(OPTIMIZATION_LEVEL,SUBSYSTEM,MODULE,ACTION, operation params..)
OPERATIONS would be first likely: ASSERT_PRINT, PRINT, ASSERT_PANIC
OPTIMIZATION_LEVELs would be first: DEVELOP, ALPHA, BETA, TEST, RELEASE, PRODUCTION, FINETUNED, EMBEDDED
SUBSYSTEMS: memory, fs, network, drivers(network, fs,...), divided to about 20 sections or so. MODULE: would be current module
ACTION: division inside module : DATA_UP, DATA_DOWN, INIT, CLEANUP, CONFIGURE, ToUserpace,FromUserSpace ... etc. about 15-25 divisions.
LDBG_DECLARE_DEBUG_VAR(OPTIMIZATION_LEVEL, SUBSYSTEM, MODULE) woudl declare a global unsigned int subsystem_module_debug = 0 and also sysctl interface to change it. the var would have ACTION bitfields, so user can control debug output runtime for the module.
elmer.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |