Re: ehea debug output discussion

[Michael Ellerman <michael@ellerman.id.au>]

[-- Attachment #1: Type: text/plain, Size: 1856 bytes --]

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
new.

cheers

-- 
Michael Ellerman
IBM OzLabs

wwweb: http://michael.ellerman.id.au
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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]