nexoniarz/SchOS
nexoniarz/SchOS
Watch
1
0
Fork
You've already forked SchOS
 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions
SchOS/projects/schinst/README.md
Nexoniarz d0f7acf9eb 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.
2026-08-09 13:47:01 +02:00

2.8 KiB
Raw Blame History

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.