Mount manager

A v2-era abstraction that lets a separate process (or plugin) handle the actual filesystem mount calls instead of the daemon doing it inline. Lives at core/mount/ (the interface and built-in mount logic) and plugins/mount/ (the manager + handlers).

Purpose

• Some snapshotters produce mount specs that are best executed in a different security domain (e.g. inside a microVM, or by a privileged helper).
• Some mount types (EROFS, fsview) are best handled by a specialized tool that knows the format.
• The manager picks the right handler for a given mount.Mount and delegates.

Plugin types

MountManagerPlugin plugin.Type = "io.containerd.mount-manager.v1"
MountHandlerPlugin plugin.Type = "io.containerd.mount-handler.v1"

A manager receives mount/unmount requests from the runtime; handlers advertise the mount types they know how to handle. The manager dispatches to the first matching handler; if none matches, it falls back to the built-in mount code in core/mount/.

Built-in handlers

Handler	Code	Mount types
erofs	plugins/mount/erofs/	EROFS read-only filesystem images
fsview	plugins/mount/fsview/	Filesystem-view (read-only overlays for image layers)

plugins/mount/ itself registers the manager.

How the runtime calls in

When the runtime is asked to start a container, it asks the snapshotter for Mounts(key). The returned []mount.Mount is then handed to the mount manager (if configured) or directly to mount.All (the legacy path). With a manager:

graph LR
    Runtime --> Manager[mount manager]
    Manager -->|matches type| Handler[erofs handler]
    Manager -->|matches type| Handler2[fsview handler]
    Manager -->|fallback| Builtin[core/mount.All]

Entry points for modification

• New mount type: implement core/mount/'s mount surface and register a MountHandlerPlugin under plugins/mount/<name>/.
• Replace the manager: register a MountManagerPlugin and disable the built-in.
• Per-platform mount logic: see core/mount/mount_linux.go, mount_windows.go, mount_freebsd.go, etc.