From: Joe Perches <joe@perches.com>
To: Toshi Kani <toshi.kani@hp.com>
Cc: lenb@kernel.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, bhelgaas@google.com,
isimatu.yasuaki@jp.fujitsu.com, liuj97@gmail.com,
srivatsa.bhat@linux.vnet.ibm.com, prarit@redhat.com,
imammedo@redhat.com, vijaymohan.pandarathil@hp.com
Subject: Re: [PATCH 1/4] ACPI: Add acpi_pr_<level>() interfaces
Date: Wed, 18 Jul 2012 14:54:12 -0700 [thread overview]
Message-ID: <1342648452.2215.12.camel@joe2Laptop> (raw)
In-Reply-To: <1342647682.3010.38.camel@misato.fc.hp.com>
On Wed, 2012-07-18 at 15:41 -0600, Toshi Kani wrote:
> On Wed, 2012-07-18 at 14:21 -0700, Joe Perches wrote:
> > On Wed, 2012-07-18 at 14:40 -0600, Toshi Kani wrote:
> > > This patch introduces acpi_pr_<level>(), where <level> is a message
> > > level such as err/warn/info, to support improved logging messages
> > > for ACPI, esp. in hotplug operations. acpi_pr_<level>() appends
> > > "ACPI" prefix and ACPI object path to the messages. This improves
> > > diagnostics in hotplug operations since it identifies an object that
> > > caused an issue in a log file.
[]
> > I'd be tempted to instead make the calls more like
> > other <subsystem>_<level> uses and rename these to
> > acpi_<level> and change the existing acpi_info to
> > another name.
[]
> I agree with you. Unfortunately, the ACPI CA (ACPI FW interpreter)
> already uses them for its internal-use as follows, so I needed to come
> up with some other name... Hence, acpi_pr_<level>.
>
> /*
> * Error reporting. Callers module and line number are inserted by AE_INFO,
> * the plist contains a set of parens to allow variable-length lists.
> * These macros are used for both the debug and non-debug versions of the code.
> */
> #define ACPI_INFO(plist) acpi_info plist
> #define ACPI_WARNING(plist) acpi_warning plist
> #define ACPI_EXCEPTION(plist) acpi_exception plist
> #define ACPI_ERROR(plist) acpi_error plist
> #define ACPI_DEBUG_OBJECT(obj,l,i) acpi_ex_do_debug_object(obj,l,i)
I wouldn't have a problem renaming a few of those to
something like:
#define ACPI_INFO(plist) acpi_old_info plist
#define ACPI_WARNING(plist) acpi_old_warning plist
#define ACPI_ERROR(plist) acpi_old_error plist
The acpi folk might though.
> > Other than that, seems fine to me.
> Great! Can I consider it as Ack? :)
Fix the kfree first.
I rarely ack stuff as other people generally have to
pick up the changes and I think acks are overrated.
cheers, Joe
next prev parent reply other threads:[~2012-07-18 21:54 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-18 20:40 [PATCH 0/4] ACPI: hotplug messages improvement Toshi Kani
2012-07-18 20:40 ` [PATCH 1/4] ACPI: Add acpi_pr_<level>() interfaces Toshi Kani
2012-07-18 21:21 ` Joe Perches
2012-07-18 21:41 ` Toshi Kani
2012-07-18 21:54 ` Joe Perches [this message]
2012-07-18 22:08 ` Toshi Kani
2012-07-19 5:35 ` Moore, Robert
2012-07-19 14:36 ` Toshi Kani
2012-07-18 21:27 ` Joe Perches
2012-07-18 21:41 ` Toshi Kani
2012-07-18 22:06 ` Joe Perches
2012-07-18 22:11 ` Toshi Kani
2012-07-18 21:59 ` Shuah Khan
2012-07-18 22:26 ` Toshi Kani
2012-07-18 22:40 ` Shuah Khan
2012-07-18 22:52 ` Toshi Kani
2012-07-18 23:18 ` Shuah Khan
2012-07-19 0:38 ` Toshi Kani
2012-07-19 16:15 ` Shuah Khan
2012-07-19 16:34 ` Joe Perches
2012-07-20 15:52 ` Toshi Kani
2012-07-19 17:28 ` Toshi Kani
2012-07-19 19:25 ` Shuah Khan
2012-07-19 20:51 ` Toshi Kani
2012-07-19 22:32 ` Shuah Khan
2012-07-19 23:43 ` Toshi Kani
2012-07-24 15:55 ` Toshi Kani
2012-07-24 16:08 ` Toshi Kani
2012-07-18 22:49 ` Joe Perches
2012-07-18 23:32 ` Toshi Kani
2012-07-18 20:40 ` [PATCH 2/4] ACPI: Update CPU hotplug messages Toshi Kani
2012-07-18 20:40 ` [PATCH 3/4] ACPI: Update Memory " Toshi Kani
2012-07-18 20:40 ` [PATCH 4/4] ACPI: Update Container " Toshi Kani
2012-07-25 3:45 ` [PATCH 0/4] ACPI: hotplug messages improvement Yasuaki Ishimatsu
2012-07-25 15:26 ` Toshi Kani
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=1342648452.2215.12.camel@joe2Laptop \
--to=joe@perches.com \
--cc=bhelgaas@google.com \
--cc=imammedo@redhat.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liuj97@gmail.com \
--cc=prarit@redhat.com \
--cc=srivatsa.bhat@linux.vnet.ibm.com \
--cc=toshi.kani@hp.com \
--cc=vijaymohan.pandarathil@hp.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).