Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
config: Document 'rbind' and 'bind' mount options extensions
They are not filesystem types, so they don't belong in 'type'. The specs claim mount(2) as inspiration for this modeling (which makes sense, since that's the syscall Linux runtimes will make to implement it), and there (recursive) bind is represented by mountflags (MS_REC | MS_BIND). Currently the 'options' property handles both mount(2)'s mountflags and data, so 'options' is a good spot for these two settings. Before this commit, we were punting this sort of table to mount(8)'s filesystem-independent mount options. With this commit we drop the mount(8) reference and replace it with explicit requirements based on mount(2), as approved by Michael [1]. Personally, I prefer the old mount(8) punt, but have been unable to get (recursive) bind documented without removing it. The option strings still come from mount(8)'s filesytem-independent mount options with the following exceptions: * move, rbind, rprivate, rshared, rslave, and runbindable are exposed in mount(8) through long options (e.g. --move). * (no)acl is listed under filesystem-specific mount options (e.g. for ext2). This commit covers the MS_* entries from [2] with the following exceptions: * MS_VERBOSE, which has been deprecated in favor of MS_SILENT. * MS_KERNMOUNT, since the mount(2) calls won't be kern_mount calls and they are not covered in mount(8). * MS_SUBMOUNT and other flags documented as "internal to the kernel". * MS_RMT_MASK, since it's a mask and not a flag. * MS_MGC_*, since the magic mount flag is ignored since Linux 2.4 according to mount(2). The example I'm touching used: "type": "bind", ... "options": ["rbind", ...] but I don't see a point to putting 'bind' in 'type' when it's not a filesystem type and you already have 'rbind' in 'options'. We could have stuck closer mount(2) by using: "options": ["recursive", "bind", ...] but while that approach extends more conveniently to the other recursive mounts (recursive shared, slave, private, and unbindable mounts), there has been resistance to a direct MS_REC analog [3,4]. I think that resistance is ungrounded (obviously the kernel and mount(2) feels like a composable MS_REC makes sense), but I'm not a mainainer. Since there are existing consumers using the old example format and similar things like runtime-tools: $ git log --oneline -1 | cat 03e8b89 Merge pull request #176 from hmeng-19/set_oom_score_adj $ ./ocitools generate --template <(echo '{}') --bind ab:cd:ro | jq '.mounts[0]' { "destination": "cd", "type": "bind", "source": "ab", "options": [ "bind", "ro" ] } this may be a breaking change for some spec consumers (although that ocitools example will still work, because 'options' contains 'bind', which means the 'type' will be ignored). But even if there are broken consumers, we're still pre-1.0, the spec never explained what bind/rbind meant before this commit, and consolidating the Linux mount spec around mount(2) now will make life less confusing in the future. [1]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2017/opencontainers.2017-05-09-20.07.log.html#l-24 [2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/fs.h?id=refs/tags/v4.11#n105 [3]: #530 (comment) [4]: #771 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
- Loading branch information