All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: dhowells@redhat.com, Al Viro <viro@zeniv.linux.org.uk>,
	Laura Abbott <labbott@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ilya Dryomov <idryomov@gmail.com>,
	Jeremi Piotrowski <jeremi.piotrowski@gmail.com>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	Phillip Lougher <phillip@squashfs.org.uk>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] vfs: Don't reject unknown parameters
Date: Tue, 17 Dec 2019 17:49:07 +0000	[thread overview]
Message-ID: <32253.1576604947@warthog.procyon.org.uk> (raw)
In-Reply-To: <CAJfpegv_zY6w6=pOL0x=sjuQmGae0ymOafZXjyAdNEHj+EKyNA@mail.gmail.com>

Miklos Szeredi <miklos@szeredi.hu> wrote:

> > So you could bloody well just leave recognition (and handling) of "source"
> > to the caller, leaving you with just this:
> >
> >         if (strcmp(param->key, "source") == 0)
> >                 return -ENOPARAM;
> >         /* Just log an error for backwards compatibility */
> >         errorf(fc, "%s: Unknown parameter '%s'", fc->fs_type->name, param->key);
> >         return 0;
> 
> Which is fine for the old mount(2) interface.
> 
> But we have a brand new API as well; do we really need to carry these
> backward compatibility issues forward?  I mean checking if a
> param/flag is supported or not *is* useful and lacking that check is
> the source of numerous headaches in legacy interfaces (just take the
> open(2) example and the introduction of O_TMPFILE).

The problem with what you're suggesting is that you can't then make
/sbin/mount to use the new syscalls because that would change userspace
behaviour - unless you either teach /sbin/mount which filesystems discard
which errors from unrecognised options or pass a flag to the kernel to shift
into or out of 'strict' mode.

David



  parent reply	other threads:[~2019-12-17 17:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-12 14:50 [PATCH] vfs: Don't reject unknown parameters Laura Abbott
2019-12-12 17:13 ` Ilya Dryomov
2019-12-12 17:47   ` Laura Abbott
2019-12-12 17:56     ` Linus Torvalds
2019-12-12 20:01       ` Laura Abbott
2019-12-12 21:36         ` Al Viro
2019-12-13  9:15           ` Miklos Szeredi
2019-12-13  9:30             ` Miklos Szeredi
2019-12-17 17:46             ` Al Viro
2019-12-17 17:49             ` David Howells [this message]
2019-12-17 18:08               ` Miklos Szeredi

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=32253.1576604947@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=idryomov@gmail.com \
    --cc=jeremi.piotrowski@gmail.com \
    --cc=labbott@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=phillip@squashfs.org.uk \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.