All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corey Minyard <minyard@acm.org>
To: Joe Perches <joe@perches.com>,
	openipmi-developer@lists.sourceforge.net,
	linux-rdma@vger.kernel.org
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH 0/6] treewide: Add and use dev_fmt similar to pr_fmt
Date: Wed, 9 May 2018 12:22:46 -0500	[thread overview]
Message-ID: <b6809bcb-f86a-df50-5a79-ad0b86d12f05@acm.org> (raw)
In-Reply-To: <ee5a0e0065047cd4d1da340f6ee924f3a31b0fac.camel@perches.com>

On 05/09/2018 12:04 PM, Joe Perches wrote:
> On Wed, 2018-05-09 at 11:47 -0500, Corey Minyard wrote:
>> On 05/09/2018 10:15 AM, Joe Perches wrote:
>>> The pr_fmt mechanism exists for pr_<level> logging message prefixing,
>>> but no similar capability exists for dev_<level> message prefixing.
>>>
>>> Many uses of dev_<level> have an embedded prefix for logging output.
>>>
>>> So add a similar dev_fmt macro that can automatically prefix the
>>> dev_<level> logging output.
>>>
>>> Rename the existing dev_<level> functions to _dev_<level> and add new
>>> macros that call _dev_<level> with the desired prefix if defined.
>>>
>>> The new default #define for dev_fmt is blank.
>>>
>>> Convert ipmi and infiniband to use this mechanism.
>> The IPMI changes look good to me.
> Oh good.
>
>> There are some conflicts with a patch I have pulling out the proc
>> interface that is destined for 3.18.
> I'm sure you mean 4.18.

Oops, yes :).  I was just looking at a 3.x kernel and it stuck in my brain.

>> I can take the IPMI changes into my tree, if you want.
> These patches are not at all urgent and were done
> on top of next-20180509.
>
> As there are dependencies between the patch that
> introduces dev_fmt and the reset of the patches,
> I think it makes sense to take these as a single
> patchset rather than take parts into various trees.

The dependency isn't hard, the changes work without dev_fmt,
it just won't print the prefix.  But I'm fine with you keeping
them.

>
> Respinning the IPMI patches is trivial and can be
> done whenever appropriate.
>
> When do you expect your IPMI patches to hit -next?
>
I went ahead and pulled it in now, it's been tested well enough
in my tree.

For patches 3, 4, and 5:

Acked-by: Corey Minyard <cminyard@mvista.com>

      reply	other threads:[~2018-05-09 17:22 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-09 15:15 [PATCH 0/6] treewide: Add and use dev_fmt similar to pr_fmt Joe Perches
2018-05-09 15:15 ` [PATCH 1/6] x86/early-quirks: Rename duplicate define of dev_err Joe Perches
2018-05-13 13:03   ` Thomas Gleixner
2018-05-13 17:30     ` Joe Perches
2018-05-13 18:09   ` [tip:x86/cleanups] " tip-bot for Joe Perches
2018-05-09 15:15 ` [PATCH 2/6] device: Add #define dev_fmt similar to #define pr_fmt Joe Perches
2018-06-19 13:31   ` Joe Perches
2018-06-24 15:41     ` Joe Perches
2018-06-25  0:51       ` Greg Kroah-Hartman
2018-07-05 22:57         ` Joe Perches
2018-07-06 13:38           ` Greg Kroah-Hartman
2018-07-06 14:42             ` Joe Perches
2018-07-06 15:30   ` Greg Kroah-Hartman
2018-07-06 15:41     ` Joe Perches
2018-07-06 15:50       ` Greg Kroah-Hartman
2018-07-06 20:50         ` Corey Minyard
2018-07-07  8:35           ` Greg Kroah-Hartman
2018-05-09 15:15 ` [PATCH 3/6] ipmi: msghandler: Add and use pr_fmt and dev_fmt, remove PFX Joe Perches
2018-05-09 15:15 ` [PATCH 4/6] ipmi: Use more common logging styles Joe Perches
2018-05-09 15:15 ` [PATCH 5/6] ipmi: Convert printk(KERN_<level> to pr_<level>( Joe Perches
2018-05-09 15:15 ` [PATCH 6/6] infiniband: qplib_fp: Use dev_fmt Joe Perches
2018-05-15 14:40   ` Doug Ledford
2018-05-15 15:01     ` Selvin Xavier
2018-05-09 16:47 ` [PATCH 0/6] treewide: Add and use dev_fmt similar to pr_fmt Corey Minyard
2018-05-09 17:04   ` Joe Perches
2018-05-09 17:22     ` Corey Minyard [this message]

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=b6809bcb-f86a-df50-5a79-ad0b86d12f05@acm.org \
    --to=minyard@acm.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=openipmi-developer@lists.sourceforge.net \
    --cc=x86@kernel.org \
    /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.