I've been working on a new mount API - a replacement for the mount(2) syscall
- with particular help from Miklós Szeredi and Al.
This has some advantages over the current API, including:
- Not limited to a single page of options.
- Options are passed separately so text and binary options can be mixed.
- Potential for better error indications.
- Internal context propagation of namespaces to submount easier.
- Options can be preparsed and stored in the internal context so that they
can be applied atomically, thereby avoiding a bug in most filesystems
whereby a partial change can be applied if an error occurs in an option.
A legacy wrapper is provided so that filesysems don't need to be modified in
order for this to go in.
There are still a few issues to be resolved, including:
(1) How many system calls should it be replaced with? Though it may not look
like it initially, mount(2) is actually a syscall switch for at least 5
or 6 different functions (create, reconfig mountpoint, reconfig super,
bind, move, change propagation flags).
(2) I'd like to treat superblocks as separate entities to mountpoints, but
this has some potentential plumbing issues as it makes mount creation,
say, a multistage process (you create a superblock, then create a
mountpoint, then bind the mountpoint). But it's not entirely clear as to
the best way to do this.
(3) How to reinstitute superblock reconfiguration. This is a place where
Miklós and I disagree. I would like to reuse the primary option parser
to fill out a context and then attempt to apply that, but Miklós would
prefer a mechanism where you specify options to be turned on and off.
The patches that I have can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=mount-context
It's currently missing some patches as I've been using it to discuss apparmor
changes with the maintainer.
David
