Messages in this thread |  | | Date | Wed, 06 Sep 2000 00:00:33 +0200 | From | Elmer Joandi <> | Subject | kernel debugging |
| |
> understanding the > > underlying principles and the code.
Speaking about that, I have been long time dreaming about following strict standard template for linux kernel functions: (macroplay intended) ---------------------- INLINE(context,level,for_speed, fixed) returntype functionname (PARM(parameters)){ DEBUG(ENTRY,SUBSYSTEM, module, functionname); /* function body starts */ do something do something on success goto ok; on failure goto failure_reason_name; /* function body ends */ ok: on ok do something DEBUG(EXIT,SUBSYSTEM, module functionname, OK); exit or return whatever failure_reason_name; on this reason do something DEBUG(EXIT,SUBSYSTEM, module, functionname, reason_name); exit or return whatever failure_reason_name1; on this reason do something DEBUG(EXIT,SUBSYSTEM, module, functionname, reason_name1); exit or return whatever }; ----------------------
You see, you try to catch somebody by following their steps. Instead, try to enchanche your own advantages.
Those two macros: DEBUG and INLINE would let the code be generated as effective as possible and as debuggable as possible. strict rule that all returns must be explicitly goto'd to the end would make code also much easier to read and would force people to formalize all failure reasons.
Closed source people have only one way to go, it is to make kernel binary fully debuggable.
Imagine kernel configuration options: which subsystems to optimize for speeed and which for size, for which to have debug options turned on, etc. Different debug macros for different situations - debugging, logging, timing. All printk's made macros and configure-time option to dump them all... that way the kernel may run in 2MB 386sx16 again for embedded devices and have lots of inlines for 2MB cache Xeon processors.
For to stay competitive, linux should less try to repeat others tricks and more try to advance those, whitch are naturally its own. Essentially the trick that everyone may recompile the kernel.
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/
|  |