I am particularly interested in this topic as well. Good suggestion. On Mon, Jan 22, 2018 at 2:40 PM, David Howells <dhowells@xxxxxxxxxx> wrote: > > 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 -- Thanks, Steve
