kernel debugging

From: Elmer Joandi (elmer@ylenurme.ee)
Date: Tue Sep 05 2000 - 17:00:33 EST


> 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/



This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:23 EST