Message-ID: <20090614121421.GA7949@localhost>
Date:	Sun, 14 Jun 2009 20:14:21 +0800
From:	Wu Fengguang <fengguang.wu@...el.com>
To:	Mike Frysinger <vapier.adi@...il.com>
Cc:	Hugh Dickins <hugh.dickins@...cali.co.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Matt Mackall <mpm@...enic.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ramfs: ignore tmpfs options when we emulate it

On Sun, Jun 14, 2009 at 07:58:29PM +0800, Mike Frysinger wrote:
> On Sun, Jun 14, 2009 at 07:49, Wu Fengguang wrote:
> > 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.
> 
> when talking about ramfs, the message is correct -- the option is
> wrong.  when talking about tmpfs emulated by ramfs, that may be a
> matter of opinion.  i can understand why you still prefer a warning,
> but there is a significant body of people out there (myself including)
> that views warnings generally as something that should be addressed.

Right. It will upset me, too. It's kind of this situation: "I knew it
(that the option takes no effect), but please shut up!" ;-)

> ignoring that, people who see warnings and dont understand what's
> going on will ask/complain/whatever to someone somewhere.  including
> an explanatory message along side the warning will make that number go
> down, but it wont go away, and it sucks to have to do that.  ive seen

Yes that's truth. People are often ignoring.

> people ask questions where they copy & paste error messages that
> already included explanatory text in it telling them how to
> fix/resolve/research the issue.  i'm sure you have too :).

Too bad this happened to me countless times..

> >> 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?
> 
> if my basic requirement is met, i dont care much about the details
> beyond that :).

OK. Let's do it the Hugh way. Thanks for the explanations!

Thanks,
Fengguang
--
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