[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1415837458.2631.13.camel@perseus.themaw.net>
Date: Thu, 13 Nov 2014 08:10:58 +0800
From: Ian Kent <raven@...maw.net>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Joe Perches <joe@...ches.com>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
autofs mailing list <autofs@...r.kernel.org>,
Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] autofs - fix log print messages
On Wed, 2014-11-12 at 15:07 -0800, Andrew Morton wrote:
> On Tue, 11 Nov 2014 14:01:52 +0800 Ian Kent <raven@...maw.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists