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

Initial commit: Schunix as it stands before the SchOS rename

Browse source 
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.
This commit is contained in:
Nexoniarz 2026-08-09 13:47:01 +02:00
commit d0f7acf9eb
275 changed files with 51417 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

60
projects/schinst/README.md Normal file
View file

@ -0,0 +1,60 @@
# 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`.