Initial commit: Schunix as it stands before the SchOS rename

An x86-64 operating system built from xv6, now largely rewritten: SMP,
a copy-on-write root filesystem (SchFS), PCI/USB/virtio drivers, a TTF
rasteriser, and a Linux-numbered syscall ABI.

No history before this point -- the tree was never under version control.
This commit exists so the rename that follows has something to undo to.

projects/schfs-linux/README.md

@@ -0,0 +1,72 @@
+# SchFS
+
+A copy-on-write filesystem, built from the ground up.
+
+SchFS is a modern-shaped filesystem in the tradition of BeFS, ZFS and btrfs: a
+copy-on-write B-tree, 64-bit object identifiers, checksummed metadata, and an
+extent-based layout. It is written from first principles rather than derived
+from an existing implementation.
+
+**Status: early.** The on-disk format works and is exercised by a test suite,
+but it is not stable and there is no compatibility promise yet. Do not put
+anything you care about on it.
+
+---
+
+## What it is
+
+| | |
+|---|---|
+| **Copy-on-write B-tree** | Metadata is never overwritten in place. An update writes new blocks and swings a pointer, so a torn write leaves the previous consistent state rather than a half-updated tree. |
+| **Objects, not paths** | Everything is a 64-bit object id. Directories are a mapping from name to id, which keeps naming a separate concern from storage. |
+| **Checksummed metadata** | CRC32c on every inode and on the superblock, verified on read. Corruption is detected where it happens rather than inferred later from strange behaviour. |
+| **Derived free space** | The free map is computed from the allocation tree rather than stored alongside it. There is no second structure to disagree with the first. |
+| **Extents** | Contiguous ranges rather than per-block pointers, so a large file costs a small number of records. |
+
+## What it is not, yet
+
+Being honest about this up front, because a filesystem's missing features are
+the part that matters:
+
+- **No snapshots.** The B-tree is copy-on-write, which is most of the machinery,
+  but nothing takes or names a snapshot yet.
+- **No journal replay** beyond what copy-on-write gives for free.
+- **No extended attributes**, no sparse-file support, no online repair.
+- **No format versioning policy.** This is the first thing being fixed — see
+  the roadmap below — because everything else is harder to change without it.
+
+---
+
+## Roadmap
+
+**1. An on-disk format version, and an upgrade path.** Not optional, and it gets
+harder every day it is postponed: the moment an image exists that somebody cares
+about, changing the layout means being able to read the old one. The superblock
+already carries a version field and a checksum; what is missing is the policy —
+a documented meaning for a version bump, a refusal to mount something newer than
+the driver understands rather than misreading it, and an explicit upgrade step.
+
+**2. FUSE.** The first Linux implementation is a FUSE filesystem, not a kernel
+module. Three reasons, in order of weight: it can be tested with `fsx` and
+`xfstests`, which are far harsher than any suite written alongside the code; it
+carries no licence entanglement, since libfuse is LGPL and used across a process
+boundary; and it can reuse the existing image-building and checking code rather
+than reimplementing the format a second time and having the two disagree.
+
+**3. A kernel module.** Only after the format is pinned and FUSE passes
+`xfstests`. Writing a kernel filesystem against a format that is still moving is
+how you end up maintaining two of them.
+
+---
+
+## Licence
+
+Apache-2.0. See [LICENSE](LICENSE).
+
+Apache-2.0 rather than MIT or BSD for one reason that matters at this level: it
+contains an express patent grant and a patent-retaliation clause. MIT and BSD
+are silent on patents, which means a contributor can hand you code and later
+assert a patent over it.
+
+Note that a Linux **kernel module** is a different licensing question from FUSE,
+and one reason the FUSE implementation comes first.