Mitmachen

nullos wächst parallel: viele Sessions, jede an ihrem Teil, alle pushen auf main.

Wie die Arbeit aufgeteilt ist

In Wellen: erst das Fundament (Bootloader, Kernel, Prompt), dann Kernel-Bausteine und Plattformen, dann libc und Shell, dann die Werkzeuge, dann Compiler und Python, zuletzt Netzwerk und mehr. Eine Welle startet erst, wenn die Schnittstellen der vorigen stehen.

Die Werkzeuge bauen Fabriken: lange laufende Sessions, die den Katalog Stück für Stück abarbeiten – erst P0, dann P1, P2, P3. Eine Abgleich-Session prüft, bis alles läuft.

Ein Werkzeug bauen – so geht's

1. git pull --rebase origin main. Gibt's cmd/<name>/ schon? Dann ist es vergeben.
2. Belegen: cmd/<name>/README.md mit Status: in Arbeit (…) anlegen, committen, sofort pushen.
3. Bauen nach dem Vorbild cmd/c/: main.c, spec, test.sh, README.md.
4. Fertig heißt: make host ohne Warnung, sh cmd/<name>/test.sh build/host/<name> sagt ok.
5. Pushen: git pull --rebase origin main && git push origin HEAD:main.

Die Spielregeln

• Nur im eigenen Ordner arbeiten. Dann gibt's keine Konflikte, auch wenn alle gleichzeitig pushen.
• Katalog, ABI, lib/, Makefile gehören der Hauptsession. Fehlt da was? Unter „Wünsche“ in die eigene README schreiben.
• Nur die Funktionen aus docs/abi.md. Sonderwünsche (Netz, Geräte, Benutzer) in eine plat_host.c und eine plat_nullos.c pro Werkzeug.
• Nichts löschen, was andere gebaut haben. Tests nur in Wegwerf-Ordnern.
• Netzwerk immer mit IPv6: IPv4 und IPv6 gleichwertig (auch [::1]:port), Tests auch auf ::1. Ohne IPv6 ist ein Netz-Werkzeug nicht fertig.
• Namen nach den Namensregeln: kurz, ein Werkzeug pro Aufgabe.

Und die Doku?

Liegt in doku/ und wird gebaut, nicht getippt: Die Kapiteltexte stehen in tools/doku/seiten/, die Werkzeugkarten kommen aus den spec-Dateien und READMEs. Neues Werkzeug? Einfach sh tools/doku/build.sh.