There's been some recent discussion about support of the "sloppy"
mount option.
It's an option that people want to get rid of from time to time and
when we do we get complaints and end up having to re-instate it.
I think the (fairly) recent mount API changes are the best way to
eliminate the need for this option over time.
That's because this option doesn't quite make sense for fsconfig() and
the knowledge of how to handle invalid options for some file systems
needs be included in the user space logic when using the mount API.
At the very least there's no way to order the options since that's
determined by the order of fsconfig() calls.
Karel Zak is in the process of adding support for the mount API to
util-linux.
Karel do you find what I'm saying is accurate?
Do you think we will be able to get rid of the sloppy option over
time with the move to use the mount API?
Assuming I am correct, we need only implement handling of the sloppy
option in the monolithic option parser which is what the attached
patch does.
If it's decided we really do need to retain this option for fsconfig()
then we could remove LEGACY from the fs_flags bit field name and add
the handling to the parameter parsing code. In this case user space
code calling fsconfig() would still need to be mindful of option order.
At this stage I've not removed the sloppy option definition from
the file systems that allow it but with the file system type flag
that should be possible too, since this is more about handling the
parse return than an actual file system option.
I'm keen to hear what people think about how we should handle this
so any comments are welcome.
---
Ian Kent (1):
vfs: handle sloppy option in fs context monolithic parser
fs/cifs/fs_context.c | 2 +-
fs/fs_context.c | 31 ++++++++++++++++++++++++++++++-
fs/nfs/fs_context.c | 2 +-
include/linux/fs.h | 1 +
4 files changed, 33 insertions(+), 3 deletions(-)
--
Ian
