Module subvolume_platform 

The operating-system operations of the migration behind one trait, and the Linux implementation. What: The operating-system operations the subvolume migration needs, behind one trait, and the Linux implementation that calls the primitives (fs_kind, fs_btrfs_ioctl, fs_clone_exchange, fs_mount_options). Why: The migration’s journal, resume, rollback and refusal logic is the same on any filesystem; only five operations need btrfs. With the operations behind a trait, the controls run the whole logic on a plain directory tree with a stand-in platform where there is no btrfs (the container gate), and run it against the real platform on btrfs (the host task). doc/planning/cli-git-btrfs-worktree.md is the design the primitives come from.

In TS you’d write (pseudocode):

interface Platform { filesystemKind(path): Kind; isSubvolumeRoot(path): boolean; createSubvolume(path): void; ... }

Structs

LinuxPlatform

What: The real platform: every operation is the primitive of the same name. Why: Production code and the host controls use it.

Traits

Platform

What: The operations of the migration that depend on the kind of filesystem. &self borrows the platform read-only so one platform serves a whole run; dyn Platform is how a caller holds “any implementation” (TS interface). Why: See the module description.