From: Wu Fengguang <fengguang.wu@intel.com>
To: Mike Frysinger <vapier.adi@gmail.com>
Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Matt Mackall <mpm@selenic.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ramfs: ignore tmpfs options when we emulate it
Date: Sun, 14 Jun 2009 19:49:35 +0800 [thread overview]
Message-ID: <20090614114935.GA7489@localhost> (raw)
In-Reply-To: <8bd0f97a0906140426g5c9ad183qa258be91c17c929d@mail.gmail.com>
On Sun, Jun 14, 2009 at 07:26:37PM +0800, Mike Frysinger wrote:
> On Sun, Jun 14, 2009 at 07:14, Wu Fengguang wrote:
> > On Sun, Jun 14, 2009 at 06:46:24PM +0800, Mike Frysinger wrote:
> >> On Sun, Jun 14, 2009 at 06:42, Wu Fengguang wrote:
> >> > On Sun, Jun 14, 2009 at 06:01:10PM +0800, Wu Fengguang wrote:
> >> > Sorry I take back the previous patch. It makes sense to not break
> >> > existing user space tools, but a warning message looks OK to remind
> >> > people of possibly unexpected behavior.
> >> >
> >> > default:
> >> > printk(KERN_ERR "ramfs: bad mount option: %s\n", p);
> >> > - return -EINVAL;
> >> > + break;
> >>
> >> hmm, if the warning was wrapped in #ifdef CONFIG_SHMEM, i'd be ok with
> >> this. otherwise we end up with warnings that can (should) be ignored
> >> when tmpfs is being emulated with ramfs.
> >
> > We may change the "ramfs:" accordingly. But *silently* ignoring
> > options is bad anyway?
>
> i really hate nitpicking such minor shit, but reality is that output
> displayed in the kernel log that is incorrect is going to cause me
> grief via customer support, updating documentation, adding FAQs,
> etc... and i doubt i'm the only one here.
I don't think the message is "incorrect" - it is reminding user the fact.
But I didn't know that ignorant users will ask you for customer
support on the "new" warning. Sorry.
> my requirement is simple: valid tmpfs options should be silently
> consumed (i.e. ignored) when tmpfs is being emulated by ramfs (i.e.
> CONFIG_SHMEM=n).
>
> so how about:
> default:
> if (!strcmp(sb->s_id, "ramfs"))
> printk(KERN_WARNING "%s: ignoring mount option: %s\n", sb->s_id, p);
> break;
This is going overly complex, maybe we just revert to Hugh's original
patch for *complete* compatibility? Sorry for making a fuss.
Thanks,
Fengguang
next prev parent reply other threads:[~2009-06-14 11:49 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-13 6:02 [PATCH] ramfs: ignore tmpfs options when we emulate it Mike Frysinger
2009-06-13 14:15 ` Hugh Dickins
2009-06-13 14:20 ` Mike Frysinger
2009-06-13 18:51 ` Matt Mackall
2009-06-14 10:01 ` Wu Fengguang
2009-06-14 10:20 ` Mike Frysinger
2009-06-14 10:43 ` Wu Fengguang
2009-06-14 10:39 ` Hugh Dickins
2009-06-14 10:48 ` Wu Fengguang
2009-06-14 16:00 ` Matt Mackall
2009-06-14 21:56 ` [PATCH] ramfs: ignore unknown mount options Hugh Dickins
2009-06-14 10:42 ` [PATCH] ramfs: ignore tmpfs options when we emulate it Wu Fengguang
2009-06-14 10:46 ` Mike Frysinger
2009-06-14 11:14 ` Wu Fengguang
2009-06-14 11:26 ` Mike Frysinger
2009-06-14 11:49 ` Wu Fengguang [this message]
2009-06-14 11:58 ` Mike Frysinger
2009-06-14 12:14 ` Wu Fengguang
2009-06-14 12:16 ` Wu Fengguang
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=20090614114935.GA7489@localhost \
--to=fengguang.wu@intel.com \
--cc=akpm@linux-foundation.org \
--cc=hugh.dickins@tiscali.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
--cc=vapier.adi@gmail.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