Messages in this thread | | | Date | Sun, 14 Jun 2009 19:49:35 +0800 | From | Wu Fengguang <> | Subject | Re: [PATCH] ramfs: ignore tmpfs options when we emulate it |
| |
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 -- 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/
| |