From: Ian Kent <raven@themaw.net>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Joe Perches <joe@perches.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
autofs mailing list <autofs@vger.kernel.org>,
Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] autofs - fix log print messages
Date: Thu, 13 Nov 2014 08:10:58 +0800 [thread overview]
Message-ID: <1415837458.2631.13.camel@perseus.themaw.net> (raw)
In-Reply-To: <20141112150700.bbb0d82dad1b133fccc1a0ec@linux-foundation.org>
On Wed, 2014-11-12 at 15:07 -0800, Andrew Morton wrote:
> On Tue, 11 Nov 2014 14:01:52 +0800 Ian Kent <raven@themaw.net> wrote:
>
> > I guess I could make a kernel.org tree but, apart from this recent
> > rename autofs4 -> autofs, the number of autofs changes hasn't warranted
> > maintaining a separate tree for quite a while.
> >
> > It looks like the place holder under /pub/scm/linux/kernel/git/raven is
> > no longer present so I expect I'd need to request that be setup.
> >
> > That's why I just send my patches to Andrew to include them in -next.
> >
> > Andrew, thoughts?
>
> Various options.
>
> a) redo these patches against mainline and I merge them into
> 3.19-rc1. Shortly after that you send me the big rename as plain
> old patches or, preferably, you send Linus a git pull request. For
> -rc2.
Given that something has gone missing along the way I'll fold these
latest patches into my original rename (and cleanup) series and resend
or whatever I end up doing.
>
> b) You run a git tree for a while.
So that would mean doing what Joe recommended and asking Stephen
Rothwell to accept pull requests for my tree, and then send the pull
request to Linus after some reasonable soak time, correct?
>
> The tree which these patches were based on seem to have more than a
> plain rename. For example I get
Right, looks like something has gone missing along the way.
The tree the patches are against is just a local clone of the Linus tree
with the patches I'd sent previously applied.
Folding these recent patches into the original series and sending one
series only that applies on the current Linus tree should sort out the
problem.
>
> --- fs/autofs4/autofs_i.h
> +++ fs/autofs4/autofs_i.h
> @@ -37,15 +37,15 @@
> /* #define DEBUG */
>
> #define DPRINTK(fmt, ...) \
> - pr_debug("pid %d: %s: " fmt "\n", \
> + pr_debug(KBUILD_MODNAME ":pid:%d:%s: " fmt "\n",\
> current->pid, __func__, ##__VA_ARGS__)
>
> #define AUTOFS_WARN(fmt, ...) \
> - pr_warn("pid %d: %s: " fmt "\n", \
> + pr_warn(KBUILD_MODNAME ":pid:%d:%s: " fmt "\n", \
> current->pid, __func__, ##__VA_ARGS__)
>
> #define AUTOFS_ERROR(fmt, ...) \
> - pr_err("pid %d: %s: " fmt "\n", \
> + pr_err(KBUILD_MODNAME ":pid:%d:%s: " fmt "\n", \
> current->pid, __func__, ##__VA_ARGS__)
>
> /*
>
>
> But I'm seeing
>
> #define DPRINTK(fmt, ...) \
> pr_debug("pid %d: %s: " fmt "\n", \
> current->pid, __func__, ##__VA_ARGS__)
>
> #define AUTOFS_WARN(fmt, ...) \
> printk(KERN_WARNING "pid %d: %s: " fmt "\n", \
> current->pid, __func__, ##__VA_ARGS__)
>
> #define AUTOFS_ERROR(fmt, ...) \
> printk(KERN_ERR "pid %d: %s: " fmt "\n", \
> current->pid, __func__, ##__VA_ARGS__)
>
> /* Unified info structure. This is pointed to by both the dentry and
>
> ie: the comment layout was changed.
next prev parent reply other threads:[~2014-11-13 0:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-11 1:29 [PATCH 1/3] autofs - fix log print messages Ian Kent
2014-11-11 1:30 ` [PATCH 2/3] autofs - change log prints to not insert newline Ian Kent
2014-11-11 1:30 ` [PATCH 3/3] autofs - use pr_xxx() calls directly for logging Ian Kent
2014-11-11 3:25 ` [PATCH 1/3] autofs - fix log print messages Joe Perches
2014-11-11 5:37 ` Ian Kent
2014-11-11 5:49 ` Joe Perches
2014-11-11 6:01 ` Ian Kent
2014-11-12 23:07 ` Andrew Morton
2014-11-13 0:10 ` Ian Kent [this message]
2014-11-13 3:50 ` Ian Kent
2014-11-11 6:07 ` Ian Kent
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=1415837458.2631.13.camel@perseus.themaw.net \
--to=raven@themaw.net \
--cc=akpm@linux-foundation.org \
--cc=autofs@vger.kernel.org \
--cc=joe@perches.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.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.