Feral
1.0.0
Feral ist ein monolithischer Kernel, genau wie ein kleines Hobbyprojekt, um ein komplettes Betriebssystem von Grund auf neu zu erstellen, auch wenn das sehr langsam ist.
Feral ist so konzipiert, dass er auf neueren PC -Systemen mit einem einigermaßen kompatiblen BIOS ausgeführt wird. Im Moment unterstützt Feral UEFI nicht, obwohl ein Hafen im Gange ist.
Feral nimmt vorerst das Vorhandensein der beiden 8259A-Bilder an, die in herkömmlichen PC-kompatiblen Mikrocomputern vorhanden sind. Auf modernen Mikros hat Ihr Southbridge, wie X399 oder X470, wahrscheinlich etwas Kompatible. In Zukunft beabsichtigt Feral, die Nutzung neuerer Prozessormerkmale wie APIC und schließlich Xapic und X2APIC zu verwenden. Darüber hinaus unterstützt Feral eine symmetrische Multiprozessierung.
Derzeit wird die getestete Hardware mit einem PC mit einem 4 "x4" -Motherboard und einem N3700-CPU ("Braswell") mit 4 GB RAM, einem 17Z-Laptop mit einem 2500U (oben genannten Zen 1) und in Zukunft und in Zukunft einen X5-Z8350 mit 2 GB Ram ("Cherr Trail") enthält.
In Zukunft soll Feral auf AARCH64 (BCM2711), Power (Sforza) und RV64GC (U540) -Hardware ausführen, wobei die Ports irgendwo in dieser Reihenfolge geschrieben wurden.
Architektonisch ist Feral ein einfacher monolithischer Kernel, der sich architektonisch mit Mach und Plan 9 ähneln, insbesondere mit letzterem. Wild bevorzugt es, die meisten Funktionen in Treiber zu bringen, anstatt direkt in den Kernel selbst eingebrannt zu werden, um mehr Flexibilität zu ermöglichen und Ressourcen als Netzwerkstandort und Steckdose aufzudecken, um besser zu reflektieren, wie moderne Prozesse und Speicher funktionieren.
Um eine Datei zu öffnen, fragt man den Dateiserver, der dem Kernel gehört, einen Prozess, der einen Socket eröffnet, der eingehende Verkehr akzeptiert. Es kann dann abhängig von der Öffnung der Sockel gelesen oder geschrieben werden.
Die Hauptidee besteht darin, die Modularität und Flexibilität von Mikrokernel zu übernehmen und sie in eine traditionelle monolithische Kernelarchitektur zu transplantieren, wodurch die Fähigkeit geopfert wird, Dinge wie das Neustart von Dateisystemtreibern zu erledigen und gleichzeitig Vorteile wie saubere Architektur, Fahrerschicht und mehrere Fahreranbieter beizubehalten.
Feral wurde für mich erstellt, um mehr über das Design von Betriebssystemen zu erfahren, während ich von der traditionellen Art von "Make Another *Nix Clone" abweist: Daran ist nichts falsch, aber ich möchte verschiedene Möglichkeiten erforschen, Hardware- und Systemfunktionen den Programmen außerhalb der Erstellung einer Datei irgendwo zu erforschen. Darüber hinaus möchte ich untersuchen, wie unterschiedlich ein neues Betriebssystem von herkömmlichen Systemen stammen kann und gleichzeitig die vorhandene Software portieren kann.
Während dieses Bild veraltet ist, da einige dieser Subsysteme in den Kernel aufgenommen werden sollten, ist dies größtenteils genau auf die Absicht:
Feral nutzt nun CMake, um zu bauen. Ein Versorgungsskript ist für den gemeinsamen Gebäudefall für x86_64 und QEMU in vm_test.sh und mit dem in vm_test_gdb.sh aktivierten GDB -Stub enthalten.
Zum manuellen Bau müssen Sie Clang als C -Compiler verwenden. Für das X86-64-PC-Ziel ohne EFI-Unterstützung können Sie die Toolchain-Datei cmake/x86_64-pc.cmake mit dem Parameter -DCMAKE_TOOLCHAIN_FILE=cmake/x86_64-pc.cmake verwenden. Dadurch wird der Kernel als "Feralker" erstellt, und es sind einige zusätzliche Schritte erforderlich, um eine bootfähige ISO -Datei zu erstellen. Weitere Informationen finden Sie in der Datei vm_test.sh .
Feral sollte auf jedem PC bequem laufen, der den X86-64-Befehlssatz (dh mindestens K8-CPU) und mindestens 1 GB Systemspeicher implementiert. Diese Speicheranforderung wird in Zukunft gesenkt, ist jedoch vorerst erforderlich, um die Dinge beim Einrichten des Kernels zunächst ein wenig zu erleichtern.
Feral erwartet, dass ein VGA-kompatibler Anzeigeadapter für einen PC vorhanden sein wird. Daher benötigen Sie eine Form von Videoadapter, die im VGA -Modus ausgeführt werden können. Die meisten CPUs der Verbraucherklasse und GPUs implementieren dies in mindestens einem ihrer GPUs.
Derzeit wird Feral ausschließlich auf virtuellen Maschinen über Zen 1 1950x und eine Handvoll kleinerer Zen -1 -Maschinen getestet. Es ist wahrscheinlich wild, dass es auf anderen Hardware gut laufen wird, aber es wird nicht getestet.
Ordner sollten so genannt werden, um unnötige Zeichen zu vermeiden (dh 'Inc' vs 'include').
Funktionen, die zwischen Modulen exportiert werden sollten, sollten im Allgemeinen die Namenskonvention von (Subsystem) (Funktionszweck) (optional-Argument-Typ) wie "KestartProcessor" haben. Wenn die Funktion architekturspezifisch ist, sollte sie mit der Architektur vorangestellt werden, zu der sie gehört, z. Weitere Informationen finden Sie unter Formating.txt
Darüber hinaus sollten Funktionen die Makros in, in Out, Opt usw. verwenden, um klar zu ermitteln, was eine Funktion mit einem Argument tut. Diese Makros erweitern sich auf nichts und sind nur da, um in der Dokumentation zu helfen.
Leichter Kernkern. Großteil der Funktionalität bei Treibern. Prozesse kommunizieren mit Libos (syscalls gehen zu einer Kernel -Tabelle, die einem Libos -Treiber sagt, dass dies genannt wurde.)
Die Fahrer behandeln Systemanrufe, mit denen "ausländische" Programme unmodifiziert werden können, wie die GNU Mach -Version von GCC oder das Lieblings -DOS -Spiel aller auf dem Mars.
Stabiler, interner Kernel Abi. Drittanbieter sollten über geringfügige Überarbeitungen hinweg arbeiten. Verwenden Sie den PNEXT -Zeiger für ernsthafte Änderungen.
Stabiles Versionsdateisystem enthalten, so dass ein versehentlicher deltree nicht alles für immer löscht. Angenommen, der Benutzer macht keine Sicherungen.
(Schließlich) erstellen Sie vollständig vulkan konforme Treiber für die GPU -Familie "Vega" und "Navi".
Unterstützen Sie X86-64 Virtualisierungserweiterungen ("Pacifica").
So etwas wie ein Chroot -Gefängnis oder ein Container, damit Wild für Serveroperationen nützlich sein kann.
Etwas, das Spaß daran hat, eines Tages nützlich zu sein?
