From: Jan-Bernd Themann <ossthema@de.ibm.com>
To: Anton Blanchard <anton@samba.org>
Cc: Thomas Klein <tklein@de.ibm.com>,
Jan-Bernd Themann <themann@de.ibm.com>,
roland@topspin.com, netdev <netdev@vger.kernel.org>,
Thomas Klein <osstklei@de.ibm.com>,
linux-ppc <linuxppc-dev@ozlabs.org>,
Christoph Raisch <raisch@de.ibm.com>,
Marcus Eder <meder@de.ibm.com>
Subject: ehea debug output discussion
Date: Mon, 14 Aug 2006 14:38:50 +0200 [thread overview]
Message-ID: <44E06EDA.6040404@de.ibm.com> (raw)
In-Reply-To: <20060813144400.GJ479@krispykreme>
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.
Regards,
Jan-Bernd
WARNING: multiple messages have this Message-ID (diff)
From: Jan-Bernd Themann <ossthema@de.ibm.com>
To: Anton Blanchard <anton@samba.org>
Cc: Thomas Klein <osstklei@de.ibm.com>,
Jan-Bernd Themann <themann@de.ibm.com>,
netdev <netdev@vger.kernel.org>,
linux-ppc <linuxppc-dev@ozlabs.org>,
Marcus Eder <meder@de.ibm.com>,
Christoph Raisch <raisch@de.ibm.com>,
Thomas Klein <tklein@de.ibm.com>,
roland@topspin.com
Subject: ehea debug output discussion
Date: Mon, 14 Aug 2006 14:38:50 +0200 [thread overview]
Message-ID: <44E06EDA.6040404@de.ibm.com> (raw)
In-Reply-To: <20060813144400.GJ479@krispykreme>
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.
Regards,
Jan-Bernd
next prev parent reply other threads:[~2006-08-14 13:17 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-09 8:39 [PATCH 3/6] ehea: queue management Jan-Bernd Themann
2006-08-09 8:39 ` Jan-Bernd Themann
2006-08-11 0:05 ` Michael Neuling
2006-08-11 0:05 ` Michael Neuling
2006-08-11 0:32 ` Alexey Dobriyan
2006-08-11 0:32 ` Alexey Dobriyan
2006-08-11 0:46 ` Michael Neuling
2006-08-11 0:46 ` Michael Neuling
2006-08-11 7:28 ` Thomas Klein
2006-08-11 7:28 ` Thomas Klein
2006-08-11 9:21 ` Jörn Engel
2006-08-11 9:21 ` Jörn Engel
2006-08-11 13:04 ` Jan-Bernd Themann
2006-08-11 13:04 ` Jan-Bernd Themann
2006-08-11 16:09 ` Thomas Klein
2006-08-11 16:09 ` Thomas Klein
2006-08-11 21:52 ` Anton Blanchard
2006-08-11 21:52 ` Anton Blanchard
2006-08-12 16:37 ` Thomas Klein
2006-08-12 16:37 ` Thomas Klein
2006-08-13 14:44 ` Anton Blanchard
2006-08-13 14:44 ` Anton Blanchard
2006-08-14 12:38 ` Jan-Bernd Themann [this message]
2006-08-14 12:38 ` ehea debug output discussion Jan-Bernd Themann
2006-08-15 0:02 ` Michael Ellerman
2006-08-15 0:02 ` Michael Ellerman
2006-08-15 5:10 ` Paul Mackerras
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=44E06EDA.6040404@de.ibm.com \
--to=ossthema@de.ibm.com \
--cc=anton@samba.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=meder@de.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=osstklei@de.ibm.com \
--cc=raisch@de.ibm.com \
--cc=roland@topspin.com \
--cc=themann@de.ibm.com \
--cc=tklein@de.ibm.com \
/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.