ehea debug output discussion

Michael Ellerman michael at
Tue Aug 15 10:02:44 EST 2006

On Mon, 2006-08-14 at 14:38 +0200, Jan-Bernd Themann wrote:
> Hi
> Anton Blanchard wrote:
> > What is going to be done about the debug infrastructure in the ehea
> > driver? The entry and exit traces really need to go, and any other debug
> > you think is important to users needs to go into debugfs or something
> > similar.
> > 
> > I see a similar issue in the ehca driver that I am in the middle of
> > reviewing.
> > 
> > Anton
> This is a statement for the eHEA driver:
> Most of the debug outputs are redundant and we'll remove them
> (EDEB_EN / EDEB_EX). We can use the standard mechanism for ethernet devices
> (netif_msg_x) in most functions of ehea_main.c as we have the device struct
> as a parameter available. However, some debug output mechanism is needed
> where the standard mechanism does not work (functions that have no relation
> to the dev struct do not have a dev parameter, for example
> ehea_hcall_9arg_9ret in ehea_phyp.h)
> The outcome of some internal discussions was that it is not acceptable for
> our enterprise users of this type of driver on this target system to need a
> recompile / reload of the driver for error analysis, so we need a mechanism
> that allows us to switch on / off debug output at runtime. Therefore, we'd
> introduce a stripped down version of EDEB.

Well, it might be better if the driver just worked, then your enterprise
users wouldn't need debugging output ;) ...

But if you think you need that facility then you should look at debugfs,
or relayfs, or just plain old printk, rather than implementing something


Michael Ellerman
IBM OzLabs

phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the Linuxppc-dev mailing list