e04ca28812
Removes the "-unix" element and with it any trademark exposure to The
Open Group.
The split follows the ecosystem layout: SchOS is the system, and the
kernel has its own name. Kernel-identity strings are the only places
that take SchIFT -- uname(2) sysname, /proc/version, and the two licence
sentences that say "kernel" outright. That is what every Unix does here:
`uname -s` on Linux reports the kernel, not the distribution. Everything
a user reads as the product -- panic screen, boot menu, error prefixes,
docs, LICENSE, NOTICE -- is SchOS.
schunix.img is schos.img, the logo assets and the musl TLS patch are
renamed, and __SCHUNIX__ is __SCHOS__ (the define and the patch that
consumes it moved together).
Two things the rename broke, both found by the bootcheck suite:
- shmtest wrote "SCHUNIX-MMAP-OK" with a hardcoded length of 15 and
compared it back by hand-counted offsets (m[3]=='U', m[14]=='K').
The shorter marker left the write running two bytes past the literal
and the compare reading past the data, failing a file-backed mmap
that was working correctly. Now written and compared through one
constant with sizeof.
- bootcheck asserted a 31-byte file after appending to
"hello-from-schunix"; the shorter string makes it 29.
Both are the same mistake: a string literal whose length is written out
somewhere else. Full suite green -- base, Tty, Ps, Sock, Fb, Usb, Evdev.
60 lines
2.8 KiB
Markdown
60 lines
2.8 KiB
Markdown
# schinst — the installer, the installation environment, and `.sip`
|
|
|
|
Getting SchOS from an ISO onto a disk.
|
|
|
|
Three separate things live here:
|
|
|
|
1. **The installation environment.** A SchOS 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` — SchOS 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`.
|