- Das als persönliches Entspannungsprojekt gestartete Bunnix war ein Experiment, wie weit sich ein Unix-ähnliches Betriebssystem für x86_64 in etwa einem Monat entwickeln lässt; tatsächlich dauerte es 27 Arbeitstage
- Der Kernel wurde überwiegend in Hare geschrieben und nutzt zusätzlich C-Komponenten wie lwext4 für ext4-Unterstützung und libvterm für das Kernel-Video-Terminal
- Es unterstützt sowohl legacy boot als auch EFI und wurde auf einigen echten Laptops getestet, erfordert wegen fehlender USB-Unterstützung aber eine PS/2-Tastatur oder PS/2-Emulation des BIOS
- Der Userspace besteht hauptsächlich aus Drittanbieter-Software wie dash, Doom, gzip, less, mandoc, sbase, tcc und Vim 5.7; die libc ist eine an Bunnix angepasste Version von musl libc
- Bunnix läuft, ist aber fehleranfällig und bleibt ein Einbenutzersystem; es ist eher ein Experiment, das in eine Überarbeitung von Helios und Verbesserungen am Kernel-Design mündet, als ein langfristig gepflegtes Projekt
Umfang und Ausführung von Bunnix
- Bunnix ist ein am 21. April 2024 gestartetes Projekt für ein Unix-ähnliches Betriebssystem für x86_64
- Ohne die Tage, an denen nicht daran gearbeitet wurde, wurden insgesamt 27 Tage investiert
- Eine direkt ausführbare Bunnix 0.0.0 iso steht bereit
- In qemu lässt sich das ISO mit folgendem Befehl booten
qemu-system-x86_64 -cdrom bunnix.iso -display sdl -serial stdio
- Das ISO kann auf einen USB-Stick geschrieben und auch auf echter Hardware gebootet werden
- Es dürfte auf den meisten AMD64-Maschinen funktionieren
- Getestet wurde es auf einem ThinkPad X220 und einem Starlabs Starbook Mk IV
- Es unterstützt sowohl legacy boot als auch EFI
- Die größte Einschränkung beim Betrieb ist die fehlende USB-Unterstützung
- Eine PS/2-Tastatur oder PS/2-Emulation des BIOS ist erforderlich
- Die meisten Laptop-Tastaturen sind per PS/2 angebunden
- Ob PS/2-Emulation für USB-Tastaturen funktioniert, hängt von der jeweiligen Umgebung ab
- Der Doom-Port hat Einschränkungen bei den Tastenbelegungen und beim Beenden
- Bewegung mit WASD
- Schießen mit der rechten Umschalttaste
- Türen öffnen mit Space
- Das Beenden des Spiels funktioniert nicht, daher muss nach dem Spielen neu gebootet werden
Kernel-Struktur und unterstützte Funktionen
- Der Bunnix-Kernel wurde größtenteils in Hare geschrieben und nutzt einige C-Komponenten
- Für ext4-Dateisystemunterstützung wird lwext4 verwendet
- Für das Kernel-Video-Terminal wird libvterm verwendet
- Die unterstützten Treiber konzentrieren sich auf grundlegende Hardware und das Booten von Speichermedien
- PCI legacy
- AHCI-Blockgeräte
- GPT- und MBR-Partitionstabellen
- PS/2-Tastatur
- Plattform-Serial-Port
- CMOS-Uhr
- vom Bootloader eingerichteter Framebuffer
- ext4- und memfs-Dateisysteme
- Auch grundlegende Kernel-Funktionen, die für ein Unix-ähnliches System nötig sind, sind enthalten
-
Virtuelles Dateisystem und Geräte
- Stellt
/dev mit Blockgeräten, den Pseudo-Geräten null, zero und full, /dev/kbd, /dev/fb0, seriellen und Video-TTYs sowie dem steuernden Terminal /dev/tty bereit
- Enthält einen recht vollständigen Terminal-Emulator und eine teilweise funktionierende termios-Unterstützung
-
Systemaufrufe und Benutzermodell
- Unterstützt rund 40 Systemaufrufe, darunter
clock_gettime, poll, openat, fork, exec, pipe, dup, dup2 und ioctl
- Derzeit ist Bunnix ein Einbenutzersystem
- Unix-Dateimodi und Eigentümerschaft werden nicht erzwungen
- Mit einigen weiteren Arbeitstagen ließe es sich in ein Mehrbenutzersystem verwandeln
Bootloader und Userspace
- Bunnix enthält zwei Bootloader
- Der Bootloader für legacy boot ist multiboot-kompatibel und in Hare geschrieben
- Der Bootloader für EFI ist in C geschrieben
- Beide Bootloader laden den Kernel bei Bedarf als ELF-Datei zusammen mit initramfs
- Der EFI-Bootloader enthält zlib zum Entpacken des initramfs
- Der multiboot-kompatible Bootloader übernimmt das Entpacken stattdessen selbst
- Der Userspace besteht größtenteils aus Drittanbieter-Quellcode
- Colossal Cave Adventure
advent
dash /bin/sh- Doom
- gzip
- less
lok /bin/awk- lolcat
- mandoc
- sbase core utils
- tcc C-Compiler
- Vim 5.7
- Die libc stammt von musl libc ab und wurde an mehreren Stellen an die Anforderungen von Bunnix angepasst
- Die curses-Bibliothek basiert auf netbsd-curses
- Das System läuft, hat aber viele Bugs und manche Implementierungen wurden hastig erstellt; mit Abstürzen ist zu rechnen
Faktoren, die die schnelle Implementierung ermöglichten, und Schwierigkeiten
- Ein Teil des Bunnix-Codes stammt aus dem früheren Projekt Helios
- Enthalten ist unter anderem Kernel-Code für gängige CPU-Einrichtung wie GDT und IDT
- Auch einige Treiber wie AHCI wurden an das Bunnix-System angepasst
- Ohne die Erfahrung mit Helios wäre es wohl schwierig gewesen, Bunnix so schnell zu bauen
- Die Integration von ext4-Unterstützung und virtuellem Terminal war besonders schwierig
- Dafür wurden die externen Abhängigkeiten lwext4 und libvterm eingebunden
- Die Dateisystemschicht wurde einige Male neu geschrieben und enthält weiterhin Bugs
- Um das Unix-Dateisystemdesign einschließlich
openat und Inode-Behandlung korrekt umzusetzen, musste tiefer in die Interna von lwext4 eingestiegen werden
- Innerhalb des Hare-Projekts wurden auch Erfahrungen damit gesammelt, Hare-, Assembly- und C-Quellen gemeinsam zu linken
- Insgesamt funktionierte das gut, aber der Aufbau der ABI-Integrationsschicht war unbequem
- Daraus entstand der Bedarf, C-Header automatisch in Hare-Forward-Declaration-Module zu konvertieren
- Entsprechende Arbeit existiert teilweise in
hare-c, aber es ist noch mehr nötig
- Das Ziel, Vim zu portieren, erhöhte die Schwierigkeit der Terminal-Implementierung
- libvterm ist eine gute Bibliothek für Terminal-Zustandsmaschinen, aber die Dokumentation ist knapp
- Für die korrekte Integration waren viele Feinabstimmungen nötig
- Auch in Performance-Optimierung wurde Zeit investiert, damit es flüssig läuft
- Der Scheduler ist ein Bereich, in dem ein großer Teil des Helios-basierten Codes verworfen und neu geschrieben wurde
- Sowohl Helios als auch Bunnix sind Single-CPU-Systeme
- Anders als Helios erlaubt Bunnix Kontextwechsel innerhalb des Kernels
- Auch präemptive Task-Wechsel gehen durch den Kernel hinein und wieder heraus
- Diese Struktur erfordert mehrere Kernel-Stacks und eine andere Art des Task-Wechsels
- Mit einem ausreichend robusten Scheduler lassen sich blockierende Operationen wie Festplattenlesevorgänge oder
pipe(2) einfach über Wait Queues implementieren
- Die Implementierung von Signalen war für Unix-Kompatibilität nötig
- Helios zielt nicht auf Unix ab und funktioniert daher auch ohne Signale
- In Bunnix wurde sie vor allem darauf ausgerichtet, dass
SIGCHLD für den dash-Port korrekt funktioniert
- Die endgültige Signal-Implementierung ist sehr grundlegend
Design-Lektionen für Helios
- Bunnix ist ein monolithischer Kernel, während Helios ein nicht auf Unix ausgelegtes Mikrokernel-Design ist
- Beim Dateisystem zeigte sich die Bedeutung von Caching
- Helios teilt die Dateisystemimplementierung auf mehrere Treiber und separate Prozesse auf
- Schon allein zum Nachverfolgen lebender Objekte ist Caching in der Dateisystemschicht wichtig
- Bei der Überarbeitung von Helios fällt viel Arbeit für das Refactoring oder Neuschreiben des Dateisystemcodes an
- Der Treiberzugriff ist in einem monolithischen Kernel von Natur aus einfacher
- Allerdings ist es nicht völlig zufriedenstellend, so viel in ring 0 zu packen
- Es gibt Spielraum, Elemente des Kontrollflusses eines monolithischen Designs in den Helios-Scheduler zu übernehmen
- In der Speicherverwaltung funktionierte der Bitmap-Allocator besser als erwartet
- In Helios sollte ein Bitmap-Allocator vermieden werden, und die Speicherverwaltung war ein großer Schmerzpunkt
- Bunnix verwendet einen einfachen Bitmap-Allocator für alle normalen Seiten des Systems
- Der Overhead war geringer als befürchtet, und er funktionierte sehr gut
- Bunnix innerhalb von 30 Tagen zu bauen, wäre mit einem Mikrokernel-Design wohl unmöglich gewesen
- Ein monolithischer Kernel ist deutlich einfacher zu implementieren
- Die Vorteile eines Mikrokernel-Designs bleiben dennoch attraktiv; die bessere Antwort könnte ein Hybrid-Kernel sein
Projektstatus und verbleibende Verbesserungskandidaten
- Bunnix ist weniger etwas, in das künftig noch viel Zeit fließen soll, sondern eher ein nahezu abgeschlossenes Kunstprojekt
- Gelegentlich kann ein paar Tage daran gearbeitet werden
- Community-Verbesserungen können als Patches über die public inbox eingereicht werden
- Die weitere OS-Entwicklung soll auf Basis der aus Bunnix gewonnenen Erkenntnisse zu Helios zurückkehren und dort größere Redesigns angehen
- Mögliche Prioritäten für Verbesserungen sind:
- Directory-Cache für Dateisysteme und allgemeine Caching-Verbesserungen
- Behebung von ext4-Bugs
- procfs und top
- Datei-mmap
- zusätzliche Signale wie
SIGSEGV
- Mehrbenutzer-Unterstützung
- NVMe-Blockgeräte
- IDE-Blockgeräte
- ATAPI- und ISO-9660-Unterstützung
- Intel-HD-Audio-Unterstützung
- Netzwerk-Stack
- Hare-Toolchain im Basissystem
- Self-Hosting
1 Kommentare
Kommentare auf Hacker News
Wirklich großartig. Musste sofort an die Geschichte denken, dass auch Unix ursprünglich in den paar Wochen entstanden sei, in denen die Familie Ritchie im Urlaub nach Kalifornien fuhr, um die Schwiegereltern zu besuchen
Quelle ist Brian W. Kernighans UNIX: A History and a Memoir
Ich bin mir gerade nicht mehr ganz sicher und müsste das nachprüfen
Zu der Stelle „Ich habe endlich gelernt, wie Signale von oben bis unten funktionieren, und es ist wirklich hässlich. Ich hatte das immer für einen der schwächsten Teile des Unix-Designs gehalten, und dieses Projekt hat meine Meinung dazu nicht geändert“ würde ich gern mehr Material sehen. Falls HN-Nutzer oder der Autor dazu mehr wissen, würde mich das interessieren
https://www.amazon.com/Advanced-Programming-UNIX-Environment...
Es behandelt die Unix-API im User Space, einschließlich Signalen und Prozessen
Wenn du Signale im Kernel implementieren willst, weiß ich nicht genau, was ich empfehlen würde, aber mir fällt zumindest https://pdos.csail.mit.edu/6.828/2012/xv6.html ein
Ein Buch zu lesen, das klar und systematisch erklärt, wie Unix funktioniert, mit in sich geschlossenen Beispielen, ist wirklich erfrischend. Wenn man C nicht kann, kann das eine Hürde sein, aber das gilt beim Lesen von Blogposts genauso
Ich glaube nicht, dass dieselben Informationen irgendwo im Web in gleichwertiger Form verfügbar sind. Auch in meinem Blog gibt es viel Unix-Kleinkram, den Leute noch lesen, aber das ist nicht auf demselben Niveau
Ich halte Unix-Signale für eines der Themen, bei denen Blogposts, Google und LLMs ein sehr ineffizienter Weg zum Verständnis sind. Selbst gebraucht ist das Buch nicht gerade „billig“, aber die Informationen sind wertvoll, deshalb hält sich der hohe Preis, und für arbeitende Programmierer ist es relativ gesehen immer noch günstig
Signale sind ein unbeholfener Versuch, asynchrone IPC nachträglich in das Design hineinzuzwängen, und deshalb anfällig für Race Conditions. Was passiert, wenn während der Signalbehandlung noch ein Signal eintrifft? Und wie geht man mit Signalen um, wenn ein Prozess gerade in einem Systemaufruf steckt? Man muss entscheiden, ob man verzögert, in eine Queue legt oder den Prozess aus dem Systemaufruf herausreißt
Wenn alle Systemaufrufe asynchron wären, wie es viele moderne Betriebssysteme als Designprinzip verfolgen, wäre dieser Teil des Problems gelöst. Und wenn es für IPC ein System wie zuverlässige Kanäle gäbe, könnte man nicht nur Signale, sondern auch anspruchsvollere asynchrone Interprozesskommunikation oder Prozeduraufrufe implementieren
SIGSTOP/SIGCONT/SIGKILL senden dem Prozess nicht wirklich ein „Signal“, sondern steuern ihn eher, also anhalten, fortsetzen, beenden
Einfache asynchrone Nachrichten wie SIGHUP, SIGUSR1, SIGUSR2, SIGTTIN, SIGTTOU werden für Dinge wie das Neuladen von Konfigurationen missbraucht, und für Daemonisierung kommen Hack-Workarounds wie nohup dazu. gunicorn verwendet die beiden letzteren sogar für dynamisches Hoch- und Runterskalieren. In diese Kategorie fallen auch seltsam spezifische Dinge wie SIGWINCH
Dann gibt es noch SIGILL, SIGSEGV, SIGFPE, die fehlerhafte Instruktionen, Segmentierungsverletzungen und Gleitkomma-Ausnahmen anzeigen. Und bei Dingen wie SIGSYS ist schon fraglich, ob sie überhaupt asynchron sein sollten
Andere Ansätze haben natürlich auch Trade-offs. Unter Windows gibt es Events, SEH, CTRL+C/CTRL+BREAK/Terminate-Handler, IOCP, Callbacks usw., und die notes von Plan 9 sind zwar nett, weil sie Strings sind und man damit beliebige Daten an andere Prozesse senden kann, aber dass für Prozesssteuerung derselbe Mechanismus verwendet wird, hat dieselben Nachteile wie bei *nix; es sind nur Strings statt Zahlen
Er behandelt die Probleme von Unix-Signalen und erklärt auch, warum signalfd, das Linux zur Behebung dieser Probleme eingeführt hat, nicht gut funktioniert
https://pubs.opengroup.org/onlinepubs/009604499/functions/bs...
Wichtig ist auch, dass Code innerhalb eines Signal-Handlers reentrant sein muss. „Nicht reentrant-fähige Funktionen sind im Allgemeinen nicht sicher aus einem Signal-Handler heraus aufzurufen“
https://man7.org/linux/man-pages/man7/signal-safety.7.html
Ich war an Hare interessiert, aber als ich diesen FAQ-Eintrag sah, wirkte das auf mich wie eine ziemlich selbstzerstörerische Politik: https://harelang.org/documentation/faq.html#will-hare-suppor...
Grundsätzlich unterstütze ich es, wenn Entwickler die Lizenz verwenden, die sie wollen, die Betriebssysteme anvisieren, die sie wollen, und den Code schreiben, den sie wollen.
Das heißt aber nicht, dass diese konkrete Politik eine gute Idee ist. Selbst die FSF, die als eine der extremsten oder prinzipientreuesten Gruppen der Freie-Software-Philosophie gilt, unterstützt Windows und POSIX. Man kann sich darüber beschweren und es Woe32 nennen, aber Stallman hat ziemlich überzeugend argumentiert, dass es dem Kampf für eine Welt ohne proprietäre Software eher hilft, wenn Freie-Software-Projekte auch auf proprietären Systemen laufen.
Bibliothekscode wird unter MPL lizenziert, daher bindet die bloße Nutzung von Hare einen nicht an eine bestimmte Lizenz. Trotzdem frage ich mich, wie lange eine Sprache lebt, die gegenüber mehr als 95 % der Desktop-Systeme die Haltung hat: „Nicht unterstützt, fragt nicht im Forum danach, kommt gar nicht erst her.“
Ironischerweise ist das erste Ergebnis bei Google für „harelang repo“ ein inoffizieller macOS-Port, und das eigentliche SourceHut-Repository taucht nicht einmal auf der ersten Seite auf.
Sprachen wachsen entweder wie ein Schneeball oder verschwinden. Ich schreibe das hier gerade auf einem Mac, könnte aber, wenn ich wollte, sofort auch eine Linux-Maschine benutzen. Warum sollte ich also eine Sprache lernen, die Entwicklern eine Reinheitsprüfung auferlegt, die nicht einmal die FSF verlangt? Ein erheblicher Teil von Open Source und Freier Software wird auf dem Mac geschrieben, und mehr als man denkt auch unter Windows.
Für mich ist genau diese Haltung von Reinheit und Ausgrenzung das, was Hare von Odin oder Zig unterscheidet. Ich wünsche viel Spaß beim Hacken und Erfolg, bin beim Letzteren aber pessimistisch.
Andererseits ist das nicht die einzige Stelle im FAQ, bei der man die Augenbrauen hochzieht.
„Es gibt keinen Paketmanager, und Code-Wiederverwendung als gemeinsamer Wert wird weniger stark gefördert.“
„qbe erzeugt langsameren Code als LLVM, und die Laufzeitleistung liegt im Bereich von 25–75 % im Vergleich zu ähnlich erzeugtem LLVM-Code.“
„Kann man in Hare Multithreading verwenden? Wahrscheinlich nicht.“
„Muss ich also meine eigene Hashtabelle implementieren? Ja. Hashtabellen sind eine verbreitete Datenstruktur, die viele Hare-Programme von Grund auf selbst implementieren müssen.“
Derzeit ist es ganz klar keine Sprache, die mit Blick auf breite Akzeptanz entworfen wurde. Das ist okay, und immerhin wird das offen gesagt.
Man hat die Freiheit, seine Meinung zu äußern, aber ich halte diese Kritik nicht für konstruktiv, wenn die Entwickler die Richtlinien bereits festgelegt haben.
Nicht jede Band muss in den Billboard-Charts landen, um hörenswert zu sein.
Betriebssysteme zu unterstützen, die die Entwickler selbst nicht benutzen, ist eine große Forderung.
Es gibt durchaus einige Sprachen, die insgesamt nicht besonders populär sind, aber in einer klar umrissenen Nische florieren und eine wichtige Rolle spielen.
Beeindruckend, sehr cool und inspirierend. Beispiele wie „etwas Beeindruckendes in X Tagen bauen“ erfordern Erfahrung und Talent, die sich über Jahre angesammelt haben.
Ich musste die englische Zeichenkette in den Katalog aufnehmen, mehrere Tests aktualisieren, Tests auf meinem lokalen System laufen lassen, die Änderungen auf den Staging-Cluster bringen, unerwartete Testfehler beheben, in Produktion ausrollen, die Übersetzer um Übersetzungen in mehrere Sprachen bitten und außerdem die Dokumentation aktualisieren.
https://www.ticalc.org/archives/files/fileinfo/463/46387.htm...
Um das zu etwas Ausgereiftem auszubauen, braucht es weniger besondere Genialität als vielmehr Ausdauer.
Es war wirklich großartig, die fast täglichen Updates auf Mastodon zu verfolgen. Man konnte sehen, wie eine erfahrene Person komplexe Software Stück für Stück zusammensetzt.
https://fosstodon.org/@drewdevault/112319697309218275
Der Code ist hier: https://git.sr.ht/~sircmpwn/bunnix/tree/master
Lizenziert unter GPLv3
Der Userspace ist größtenteils aus Drittquellen zusammengesetzt.
Ich war zuerst überrascht, als beim Klick auf die ISO ein 60-MB-Download erschien, aber dann habe ich verstanden, warum.
Zum Vergleich: Linux 0.01 war ein 71-KB-Download, enthielt aber nur den Kernel-Quellcode.
Hare wirkt wie eine interessante Sprache.
Allerdings dürfte in diesem Multicore-Zeitalter die folgende Einschränkung die Verbreitung begrenzen.
Laut FAQ https://harelang.org/documentation/faq.html wird auf die Frage, ob man in Hare Multithreading verwenden kann, mit „wahrscheinlich nicht“ geantwortet.
Für die Multiplexierung von I/O-Aufgaben werden Event-Loops empfohlen, und wenn CPU-Ressourcen parallel genutzt werden müssen, Multiprozesse mit Shared Memory.
Streng genommen kann man in Hare-Programmen Threads erzeugen. Man kann gegen libc linken und pthreads verwenden oder den Systemaufruf
clone(2)direkt nutzen. Mit Hare implementierte Betriebssysteme wie Helios implementieren üblicherweise Multithreading.Allerdings garantiert die Upstream-Standardbibliothek keine Reentranz, daher trägt man selbst die volle Verantwortung dafür, sich nicht ins eigene Bein zu schießen.
Ich persönlich bevorzuge diesen Ansatz für die meisten Anwendungsfälle, weil er die Möglichkeit von Datenrennen auf den Shared-Memory-Bereich beschränkt. Aus Sicht von Datenrennen fühlt es sich an wie ein „unsafe block“ im Speicher.
Stammt aus „Linux System Call Table – Chromiumos“ https://www.chromium.org/chromium-os/developer-library/refer... https://news.ycombinator.com/item?id=33395777
google/syzkalleR
Fuschia / Zircon-Systemaufrufe: https://fuchsia.dev/fuchsia-src/reference/syscalls
„Memory Sealing ‘Mseal’ System Call Merged for Linux 6.10“
https://news.ycombinator.com/context?id=40474551