Messages in this thread | | | Date | Sun, 14 Jun 2009 20:14:21 +0800 | From | Wu Fengguang <> | 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |