New mount API: implement fsopen(2), fsconfig(2), fsmount(2), move_mount(2).#13350
Open
copybara-service[bot] wants to merge 1 commit into
Open
New mount API: implement fsopen(2), fsconfig(2), fsmount(2), move_mount(2).#13350copybara-service[bot] wants to merge 1 commit into
copybara-service[bot] wants to merge 1 commit into
Conversation
c213366 to
4d0f1eb
Compare
…nt(2). The first step in implementing the new file-descriptor based mount API in gVisor. A "filesystem creation context" is created using fsopen(). The context is then configured using fsconfig(), and the FSCONFIG_CMD_CREATE command is used to create a filesystem. A "mount object" can be obtained using fsmount(), which can be operated on directly using the *at() functions or mounted onto the real directory tree using move_mount(). For compatibility reasons, the new mount API is gated behind the runtime flag `--new-mount-api`, which is disabled by default. The current implementation has the following limitations: - Linux passes configuration options to filesystems on-the-fly as fsopen() and fsconfig() are called, allowing per-parameter error handling. gVisor currently queues up all options and passes them to the filesystem all-at-once when FSCONFIG_CMD_CREATE occurs. Lifting this will require refactoring the option parsing for all existing filesystems. - Only flag and string arguments to fsconfig() are supported. - Reconfiguration of the filesystem through fsconfig() is not supported. - move_mount(): flags MOVE_MOUNT_SET_GROUP and MOVE_MOUNT_BENEATH are not supported. - The filesystem context message retrieval interface is not supported. In the interest of review size, there is no implementation yet for open_tree(2) or fspick(2). PiperOrigin-RevId: 923640824
4d0f1eb to
858028a
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
New mount API: implement fsopen(2), fsconfig(2), fsmount(2), move_mount(2).
The first step in implementing the new file-descriptor based mount API in
gVisor. A "filesystem creation context" is created using fsopen(). The context
is then configured using fsconfig(), and the FSCONFIG_CMD_CREATE command is
used to create a filesystem. A "mount object" can be obtained using fsmount(),
which can be operated on directly using the *at() functions or mounted onto the
real directory tree using move_mount().
For compatibility reasons, the new mount API is gated behind the runtime flag
--new-mount-api, which is disabled by default.The current implementation has the following limitations:
fsconfig() are called, allowing per-parameter error handling. gVisor
currently queues up all options and passes them to the filesystem all-at-once
when FSCONFIG_CMD_CREATE occurs. Lifting this will require refactoring the
option parsing for all existing filesystems.
supported.
In the interest of review size, there is no implementation yet for
open_tree(2) or fspick(2).