Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
config: Document 'recursive' 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. We may eventually add entries for other mount(8) command-line options (e.g. --move, --make-shared, ...), but I've left those off until someone pitches a motivational use case for them. 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 to that example with an unset type and: "options": ["rbind", ...] and that would have been closer to mount(8)'s --rbind API, but I've gone with 'recursive' here to stay closer to mount(2). This will scale better if/when we eventually add options for MS_SLAVE, etc. Since there are existing consumers using the old example format and similar things like: $ git log --oneline -1 | cat 03e8b89 Merge pull request opencontainers#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. Signed-off-by: W. Trevor King <wking@tremily.us>
- Loading branch information