Thread (42 messages) 42 messages, 5 authors, 2019-06-21

Re: [PATCH 04/25] vfs: Implement parameter value retrieval with fsinfo() [ver #13]

From: David Howells <dhowells@redhat.com>
Date: 2019-06-18 22:34:59
Also in: linux-fsdevel, lkml

Miklos Szeredi [off-list ref] wrote:
Again, don't blindly transform s_flags into options, because some of
them may have been internally manipulated by the filesystem.
In what filesystems do I need to undo this manipulation?
You could do a helper for filesystems that does the the common ones
(ro/sync/dirsync) but all of that *should* go through the filesystem.
I don't agree, but since you keep insisting, I've changed the helper function
that renders these so that it now takes s_flags as an argument and is called
from generic_fsinfo() if the filesystem doesn't handle FSINFO_ATTR_PARAMETERS.

Therefore, every filesystem that handles FSINFO_ATTR_PARAMETERS, *must* call
the function itself (or do the noting directly) otherwise these parameters
will not get rendered.

The helper function has been exported, and the calling filesystem can give any
s_flags it likes.  All the filesystems so far just use
path->dentry->d_sb->s_flags.
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.

David
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help