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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
