ehea debug output discussion
Michael Ellerman
michael at ellerman.id.au
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
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
-------------- 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: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20060815/5463b0dc/attachment.pgp>
More information about the Linuxppc-dev
mailing list