design: describe the role of the mount

Signed-off-by: Stephen J Day <stephen.day@docker.com>

design/mounts.md

@@ -0,0 +1,32 @@
+# Mounts
+
+Mounts are the main interaction mechansim in containerD. Container systems of
+the past typically end up having several disparate components independently
+perform mounts, resulting in complex lifecycle management and buggy behavior
+when coordinating large mount stacks.
+
+In containerD, we intend to keep mount syscalls isolated to the container
+runtime component, opting to have various components produce a serialized
+representation of the mount. This ensures that the mounts are performed as a
+unit and unmounted as a unit.
+
+From an architecture perspective, components produce mounts and runtime
+executors consume them.
+
+More imaginitive use cases include the ability to virtualize a series of mounts
+from various components without ever having to create a runtime. This will aid
+in testing and implementation of satellite components.
+
+## Structure
+
+The `Mount` type follows the structure of the historic mount syscall:
+
+| Field | Type | Description |
+|-------|----|-------------|
+| Type | `string` | Specific type of the mount, typically operating system specific |
+| Target | `string` | Intended filesystem path for the mount destination. |
+| Source | `string` | The object which originates the mount, typically a device or another filesystem path. |
+| Options | `[]string` | Zero or more options to apply with the mount, possibly `=`-separated key value pairs. | 
+
+We may want to further parameterize this to support mounts with various
+helpers, such as `mount.fuse`, but this is out of scope, for now.