All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miklos Szeredi <miklos@szeredi.hu>
To: David Howells <dhowells@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>, Ian Kent <raven@themaw.net>,
	Linux API <linux-api@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Miklos Szeredi <mszeredi@redhat.com>
Subject: Re: [PATCH 04/25] vfs: Implement parameter value retrieval with fsinfo() [ver #13]
Date: Wed, 19 Jun 2019 08:33:40 +0200	[thread overview]
Message-ID: <CAJfpegtXp0bQRFGaZia_MGmFGFjKG5XoCnDCy=onmsWBJGHMHw@mail.gmail.com> (raw)
In-Reply-To: <24127.1560897289@warthog.procyon.org.uk>

On Wed, Jun 19, 2019 at 12:34 AM David Howells <dhowells@redhat.com> wrote:

> > Same goes for vfs_parse_sb_flag() btw.   It should be moved into each
> > filesystem's ->parse_param() and not be a mandatory thing.
>
> I disagree.  Every filesystem *must* be able to accept these standard flags,
> even if it then ignores them.

"posixacl" is not a standard flag.  It never was accepted by mount(8)
so I don't see where you got that from.

Can you explain why you think "mand", "sync", "dirsync", "lazytime"
should be accepted by a filesystem such as proc?  The argument that it
breaks userspace is BS, because this is a new interface, hence by
definition we cannot break old userspace.  If mount(8) wants to use
the new API and there really is breakage if these options are rejected
(which I doubt) then it can easily work around that by ignoring them
itself.

Also why should "rw" not be rejected for filesystems which are
read-only by definition, such as iso9660?

Thanks,
Miklos

  reply	other threads:[~2019-06-19  6:33 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-28 15:11 [PATCH 00/25] VFS: Introduce filesystem information query syscall [ver #13] David Howells
2019-05-28 15:11 ` [PATCH 01/25] vfs: syscall: Add fsinfo() to query filesystem information " David Howells
2019-05-29  7:42   ` Miklos Szeredi
2019-06-18 22:24   ` David Howells
2019-05-28 15:11 ` [PATCH 02/25] vfs: Allow fsinfo() to query what's in an fs_context " David Howells
2019-06-21  9:47   ` Christian Brauner
2019-06-21 13:12   ` David Howells
2019-06-21 13:16     ` Christian Brauner
2019-06-21 13:16       ` Christian Brauner
2019-06-21 13:28       ` Christian Brauner
2019-06-21 14:50       ` David Howells
2019-05-28 15:11 ` [PATCH 03/25] vfs: Allow fsinfo() to be used to query an fs parameter description " David Howells
2019-05-28 15:11 ` [PATCH 04/25] vfs: Implement parameter value retrieval with fsinfo() " David Howells
2019-05-29  8:08   ` Miklos Szeredi
2019-06-18 22:34   ` David Howells
2019-06-19  6:33     ` Miklos Szeredi [this message]
2019-05-28 15:11 ` [PATCH 05/25] fsinfo: Implement retrieval of LSM parameters " David Howells
2019-05-28 15:11 ` [PATCH 06/25] vfs: Introduce a non-repeating system-unique superblock ID " David Howells
2019-05-28 15:12 ` [PATCH 07/25] vfs: Allow fsinfo() to look up a mount object by " David Howells
2019-05-28 15:12 ` [PATCH 08/25] vfs: Add mount notification count " David Howells
2019-05-28 15:12 ` [PATCH 09/25] vfs: Allow mount information to be queried by fsinfo() " David Howells
2019-06-01 16:08   ` Joel Fernandes
2019-06-05 12:21   ` Alan Jenkins
2019-06-18 14:00   ` David Howells
2019-05-28 15:12 ` [PATCH 10/25] vfs: fsinfo sample: Mount listing program " David Howells
2019-06-05 12:22   ` Alan Jenkins
2019-05-28 15:12 ` [PATCH 11/25] hugetlbfs: Add support for fsinfo() " David Howells
2019-05-28 15:12 ` [PATCH 12/25] kernfs, cgroup: Add fsinfo support " David Howells
2019-05-28 15:12 ` [PATCH 13/25] fsinfo: Support SELinux superblock parameter retrieval " David Howells
2019-05-28 15:13 ` [PATCH 14/25] fsinfo: Support Smack " David Howells
2019-05-28 15:13 ` [PATCH 15/25] afs: Support fsinfo() " David Howells
2019-05-28 15:13 ` [PATCH 16/25] nfs: " David Howells
2019-05-28 15:13 ` [PATCH 17/25] fsinfo: autofs - add sb operation " David Howells
2019-05-28 15:13 ` [PATCH 18/25] fsinfo: shmem - add tmpfs " David Howells
2019-05-28 15:13 ` [PATCH 19/25] fsinfo: proc - add " David Howells
2019-05-28 15:13 ` [PATCH 20/25] fsinfo: devpts " David Howells
2019-05-28 15:14 ` [PATCH 21/25] fsinfo: pstore " David Howells
2019-05-28 15:14 ` [PATCH 22/25] fsinfo: debugfs " David Howells
2019-05-28 15:14 ` [PATCH 23/25] fsinfo: bpf " David Howells
2019-05-28 15:14 ` [PATCH 24/25] fsinfo: ufs " David Howells
2019-05-28 15:14 ` [PATCH 25/25] fsinfo: Add API documentation " David Howells
2019-06-05 12:21   ` Alan Jenkins
2019-06-18 14:01   ` David Howells

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='CAJfpegtXp0bQRFGaZia_MGmFGFjKG5XoCnDCy=onmsWBJGHMHw@mail.gmail.com' \
    --to=miklos@szeredi.hu \
    --cc=dhowells@redhat.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mszeredi@redhat.com \
    --cc=raven@themaw.net \
    --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.