[U-Boot] DEBUG macro granularity

[U-Boot] DEBUG macro granularity

[Simon Glass]

Hi,

There is a great big DEBUG define which determines whether debug() is a
printf() or a nop. This is used by various modules to make them more verbose
which is helpful sometimes.

Some modules have their own finer control over this, for example USB_DEBUG
in common/usb.c. Also:

$ grep -rsl _PRINTF\( .
./board/mpl/pati/pati.c
./board/mpl/common/usb_uhci.c
./board/esd/common/xilinx_jtag/micro.c
./common/usb_kbd.c
./common/usb_ether.c
./common/usb_storage.c
./common/usb.c
./arch/sparc/cpu/leon3/usb_uhci.c
./issue5563011_1.diff
./drivers/bios_emulator/x86emu/decode.c
./drivers/bios_emulator/x86emu/ops.c
./drivers/bios_emulator/x86emu/ops2.c
./drivers/bios_emulator/include/x86emu/debug.h

Recently I enabled DEBUG and got rather a lot of output, enough that it took
hours to boot a kernel (every MMC block printed a nice message from the GPIO
driver). I understand that creating these local DEBUG macros is frowned
upon, but without this it tends to make the U-Boot-wide DEBUG setting so
verbose as to be useless. It also means that every potentially verbose
module needs an '#undef DEBUG' at the top, which means the global flag is
overridden.

Can I suggest perhaps a way of allowing some sort of granularity in the
design, rather than just relying on hacking in DEBUG in each file? What is
the recommended approach, please?

Regards,
Simon

[U-Boot] DEBUG macro granularity

[Wolfgang Denk]

Dear Simon Glass,

In message <AANLkTik7dQqC8-m5pmXqiT1ObPhKTPTPbqu=TucMAk=n@mail.gmail.com> you wrote:
>
> There is a great big DEBUG define which determines whether debug() is a
> printf() or a nop. This is used by various modules to make them more verbose
> which is helpful sometimes.
> 
> Some modules have their own finer control over this, for example USB_DEBUG
> in common/usb.c. Also:

This is usually code that was imported from other projects (like the
Linux kernel) where their debug facilities were left in place to make
later updates easier.

> Recently I enabled DEBUG and got rather a lot of output, enough that it took
> hours to boot a kernel (every MMC block printed a nice message from the GPIO
> driver). I understand that creating these local DEBUG macros is frowned
> upon, but without this it tends to make the U-Boot-wide DEBUG setting so
> verbose as to be useless. It also means that every potentially verbose
> module needs an '#undef DEBUG' at the top, which means the global flag is
> overridden.

No, this is not the way we usually work.

> Can I suggest perhaps a way of allowing some sort of granularity in the
> design, rather than just relying on hacking in DEBUG in each file? What is
> the recommended approach, please?

The normal method is to NOT enable DEBUG globally, but only in the
source files which you really want to debug. You can do this either by
board-specific compiler flags, or (usually easier) by simply adding a
"#define DEBUG" in the respective source files (before the first
#include line).

If you need a fancier approach please go on and implement it.  Patches
welcome.

> --0015175cba1884847f049addd00c
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable

Please never post HTML here.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Obviously, a major malfunction has occurred."
              -- Steve Nesbitt, voice of Mission Control, January 28,
                 1986, as the shuttle Challenger exploded within view
                 of the grandstands.