d0f7acf9eb
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.
60 lines
2.8 KiB
Markdown
60 lines
2.8 KiB
Markdown
# schinst — the installer, the installation environment, and `.sip`
|
|
|
|
Getting Schunix from an ISO onto a disk.
|
|
|
|
Three separate things live here:
|
|
|
|
1. **The installation environment.** A Schunix that boots from the ISO into a
|
|
known state with the installer running instead of a login shell. The ISO
|
|
already boots to userspace without a hard disk (`make iso`), so this is a
|
|
different init and a different root, not a different kernel.
|
|
2. **`.sip` tooling.** `mksip` to capture a tree into a package, and the apply
|
|
path that unpacks one onto a filesystem.
|
|
3. **The installer itself.** Partition, make a filesystem, apply the `.sip`,
|
|
install the bootloader, reboot.
|
|
|
|
## Status
|
|
|
|
Not started. `.sip` needs its format written down before any code exists.
|
|
|
|
## `.sip` — Schunix Installation Package
|
|
|
|
The stated model is WIM, the image format Windows PE installs from, and the
|
|
thing worth copying from WIM is that it is **file-based, not block-based**.
|
|
|
|
A block image (`.img`, `.iso`) is a byte-for-byte copy of a partition. It can
|
|
only be applied to a partition of the same size or larger, it carries the
|
|
free space and the fragmentation of the machine it came from, and two images
|
|
that share 90% of their files share nothing on disk.
|
|
|
|
A file-based image stores files and metadata. It can be applied to any
|
|
filesystem of any size, it carries no free space at all, and identical files
|
|
across images are stored once.
|
|
|
|
Sketched structure — one header, one index, one blob store:
|
|
|
|
```
|
|
header magic, version, blob count, index offset, uncompressed size
|
|
index per file: path, mode, uid/gid, mtime, size, content hash
|
|
(directories and symlinks are index entries with no blob)
|
|
blob store content-addressed, one entry per distinct hash, compressed
|
|
```
|
|
|
|
Deduplication falls out of content addressing rather than being a feature:
|
|
two identical files hash the same and there is only one blob. **Most of this
|
|
already exists.** `tools/mkschfs.c` and `tools/mkfs.c` both do exactly this
|
|
dedup, with an `(st_dev, st_ino)` fast path so a hard link is not hashed
|
|
twice, and SchFS's B-tree is already content addressed. `mksip` should share
|
|
that code rather than reimplement it — that was the reason the dedup was
|
|
factored the way it was.
|
|
|
|
Open questions, all of which want deciding before code:
|
|
|
|
- Compression. Something with a small decompressor is worth more here than
|
|
something with a good ratio, because the decompressor has to run in the
|
|
installation environment.
|
|
- Whether multiple images per `.sip` (WIM's real trick — install, recovery
|
|
and boot images sharing one blob store) is worth the complexity now.
|
|
- Whether the kernel can mount a `.sip` read-only directly. It is close to a
|
|
filesystem already, and if it can, the installation environment's root can
|
|
simply *be* the `.sip`.
|