All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Gurevich <vag@paulidav.org>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [RFD] Consistent debugging output structure
Date: Sat, 22 Mar 2003 13:35:20 -0800	[thread overview]
Message-ID: <3E7CD718.2090506@paulidav.org> (raw)
In-Reply-To: 20030322102847.GF28544@pengutronix.de

Hello Robert,

Robert Schwebel wrote:
> What we don't agree on is if we need several debug levels. What do the
> others think? For more complex drivers like the ethernet ones this is
> really useful. 

Based on how I normally do this sort of debugging in my drivers
these are the questions I ask myself:

1) Do I want dynamic debugging levels (i.e. the ones I can choose
    at runtime). If the answer is "yes" then debug level should be
    stored in a variable, otherwise it should be a macro.

2) How big the performance hit will be and how important it is?
    If I don't mind performance hit, then I have dynamic debugging
    with default level "0". Otherwise I use a macro and let the
    compiler optimize it out.

About debug levels. Normally I use bits to specify what do I want
to debug instead of relying on "greater than" comparisons. This way
I have much greater flexibility and can enable only the debug outputs
I really need right now.

Here what it normally translates to in C:
===========================================================
/*
  *  Debug levels for my driver (say, vag01)
  */
enum {
     DEBUG_VAG01_INIT    = 0x00000001, /* Initialization sequence   */
     DEBUG_VAG01_INTR    = 0x00000002, /* Interrupt handling        */
     DEBUG_VAG01_API     = 0x00000004, /* Standard API calls (open, */
                                       /* close, read, write, etc.  */
     DEBUG_VAG01_RX      = 0x00000008, /* Receive data path         */
     DEBUG_VAG01_TX      = 0x00000010, /* Transmit data path        */
     DEBUG_VAG01_RX_DATA = 0x00000014, /* Dump received data        */
     DEBUG_VAG01_TX_DATA = 0x00000018, /* Dumt transmit data        */
     DEBUG_VAG01_RELOCK  = 0x00000020, /* Debug relock thread       */
};
/*
  * Compile-time configuration parameters for the driver vag01
  */
#define DEBUG_VAG01           /* No debugging compiled in if it */
                               /* is not defined                 */

#define DEBUG_VAG01_DEFAULT 0 /* The initial debug level. Can be */
                               /* (DEBUG_VAG01_INTR | DEBUG_VAG01_API) 
*/
                               /* or something like that */

/*
  * Here is the debug print
  */
#if defined (DEBUG_VAG01)
#define debug(level, fmt, args...)    \
     do {                              \
        if (debug_vag01 & (level)) {   \
            printf(fmt , ##args);      \
        }                              \
     } while (0)
#else
#define debug(level, fmt, args...)
#endif

/*
  * Here is the debug level variable
  */
static __u32 debug_vag01 = DEBUG_VAG01_DEFAULT;

===============================================================

Some other comments:
   1) I use an anonymous enum to define debug levels. This way it
      becomes easier to change them from gdb by typing:

      (gdb) set debug_vag01|=(DEBUG_VAG01_TX | DEBUG_VAG01_RX)

   2) When I am doing that for Linux I also provide /proc interface
      to change this debug level dynamically (plus a "debug" module
      parameter, or course)

   3) In case of multiple devices of the same type (not quite important
      for u-boot) you can move the debug_level variable into the driver
      instance structure

   4) Again, probably not important for u-boot, but important for a
      Linux-based system: it becomes very easy to add a registration
      API so that each debuggable component could register its levels
      with a centralized debug command. Then you can easily control
      debug levels by typing
          debug <component> <level>
          undebug <component> <level>
          show debug
          show debug <component>
      pretty much the same like Cisco IOS does.

   5) Checking the debug level upsets the cache and this might become
      important in the performance critical parts. Then I use a couple
      more compile-time flags to remove just this debug from the
      production-level code.

Just my 2 cents.

Best regards,
Vladimir Gurevich

  reply	other threads:[~2003-03-22 21:35 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-19 18:32 [U-Boot-Users] [RFD] Consistent debugging output structure Robert Schwebel
2003-03-22 10:28 ` Robert Schwebel
2003-03-22 21:35   ` Vladimir Gurevich [this message]
2003-03-23  0:51     ` Vladimir Gurevich
2003-03-23 14:32   ` Wolfgang Denk
2003-03-24  6:29     ` Robert Schwebel
2003-03-24  8:14       ` Wolfgang Denk
2003-03-24  8:23         ` Robert Schwebel
2003-03-24  8:52           ` Wolfgang Denk
2003-03-24  8:59             ` Robert Schwebel
2003-03-24  9:10               ` Wolfgang Denk
2003-03-24  7:44     ` Holger Schurig
2003-03-24  8:36       ` Robert Schwebel
2003-03-24  8:57         ` Wolfgang Denk
2003-03-24  9:03           ` Robert Schwebel
2003-03-24  9:19             ` Wolfgang Denk
2003-03-24  8:50       ` Wolfgang Denk
2003-03-24  9:00         ` Robert Schwebel
2003-03-24  9:16           ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3E7CD718.2090506@paulidav.org \
    --to=vag@paulidav.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.