LF OS — Änderungen 11512 → 11518

Zeile 10: Zeile 10:
 
| Plattform = [[x86-64]]
 
| Plattform = [[x86-64]]
 
| IPC = Vor allem shared memory und message passing
 
| IPC = Vor allem shared memory und message passing
−
| Homepage = [https://praios.lf-net.org/littlefox/lf-os_amd64 https://praios.lf-net.org/littlefox/lf-os_amd64]
+
| Homepage =  
 +
* [https://praios.lf-net.org/littlefox/lf-os_amd64 Eigenes Gitlab mit CI und Issues]
 +
* [https://github.com/LittleFox94/lf-os_amd64 GitHub Mirror (nur master Branch)]
 +
* [https://littlefox.narf.press/lf-os_amd64 Doku auf Gitlab Pages]
 
}}
 
}}
  
Zeile 19: Zeile 22:
 
* Microkernel
 
* Microkernel
  
−
Der Plan ist, quasi alles in Userspace-Prozesse zu packen. Alle Prozesse können Dienste bereitstellen, diese werden im Kernel registriert. Andere Prozesse können sich dann Dienste erfragen und bekommen dann PID und Channel ID für IPC um mit dieser Instanz des Dienstes zu kommunizieren. Dienste sind z.B. Blockdevice-Treiber, FS-Treiber, Grafikserver, Terminals, ...
+
Der Plan ist, quasi alles in Userspace-Prozesse zu packen. Alle Prozesse können Dienste bereitstellen, diese werden im Kernel registriert. Andere Prozesse können sich dann Dienste erfragen und bekommen dann Informationen für IPC um mit diesem Dienstes zu kommunizieren. Dienste sind z.B. Blockdevice-Treiber, FS-Treiber, Grafikserver, Terminals, ...
  
−
Wenn Dienste von Prozessen implementiert werden und diese Forken, werden die Dienste direkt als Standardimplementierung im fork verwendet. So kann ein Terminal-Emulator z.B. den Terminal Dienst implementieren und in eine Shell forken, die dann automatisch auf diesen Terminal Emulator rendert.
+
Welche Implementierung standardmäßig verwendet werden soll, lässt sich von Prozessen konfigurieren und bei <code>fork()</code> vererben, dadurch ergibt sich eine Art "Dependency Injection". Darüber lässt sich z.B. <code>chroot()</code> abbilden (anderen FS Dienst als Standard setzen), der Compositor stellt selber wieder einen Grafikserver bereit pro Fenster (in dem ein weiterer Compositor laufen kann..), ein Outbound-Firewall Dienst ist auch nur eine Implementierung von ''Netzwerkinterface-Dienst'' .. so die Idee.
  
−
Bis das so weit läuft wirds aber wohl noch etwas dauern ... gerade funktioniert schon
+
== Was funktioniert bereits ==
  
 
* UEFI Loader
 
* UEFI Loader
 
** lädt Kernel und init
 
** lädt Kernel und init
−
** bereitet sinnvolle initiale Speichermappings vor
+
** bereitet sinnvolle initiale Speichermappings vor und holt memory map von der Firmware
−
** Holt Framebuffer vom UEFI für Konsole
+
** bereitet framebuffer für Konsole vor (UEFI GraphicsOutputProtocol)
 
* Kernel
 
* Kernel
−
** physische Speicherverwaltung mit linked lists
+
** physische Speicherverwaltung mit linked lists  
−
** virtuelle Speicherverwaltung unter Verwendung der Datenstrukturen die die CPU selbst verwendet
+
** virtuelle Speicherverwaltung (nutzt aktuell einfach die Paging-Strukturen, braucht noch mehr Infos für Copy-on-Write Referenzzähler z.B.)
 
*** es gibt ein Mapping des gesamten physischen Speichers an eine virtuelle Adresse
 
*** es gibt ein Mapping des gesamten physischen Speichers an eine virtuelle Adresse
−
*** Informationen wofür Pages verwendet werden ist aktuell in Arbeit
+
**** dabei wird sogar ausgewählt ob 2MB oder 1GB Pages sinnvoller sind
 
** Scheduler
 
** Scheduler
−
** schönes Logging in den Arbeitsspeicher und COM1 (und auf die Konsole bis ein Prozess den Framebuffer übernimmt)
+
** schönes Logging in den Arbeitsspeicher und COM1 (und auf die Framebuffer-Konsole bis ein Prozess den Framebuffer übernimmt)
 
** ein paar coole Datenstrukturen, ein paar Unit-Tests für diese
 
** ein paar coole Datenstrukturen, ein paar Unit-Tests für diese
−
** ein paar Syscalls - definiert in einer YAML Datei und automatisch zu C-Code gemacht (Kernel- und Userspace-seitig)
+
** ein paar Syscalls - definiert in einer YAML Datei aus der automatisch C-Code generiert wird (Kernel- und Userspace-seitig)
 +
** genug [[ELF]] Loader für Binaries die LLD ausspuckt (Segmente sind Page-aligned aber irgendwie auch nicht)
 +
** Panic screen mit Stacktrace (sogar mit Kernel Debug-Symbolen!)
 +
** Faults werden größtenteils dem Prozess zugeschoben, manche Page-Faults sogar sinnvoll behandelt (Stack)
 
** Anfänge von [[POSIX Threads |pthreads]] -> aktuell aktivste Baustelle
 
** Anfänge von [[POSIX Threads |pthreads]] -> aktuell aktivste Baustelle
 
* init
 
* init
Zeile 43: Zeile 49:
 
** forkt dabei, nutzt pthread_mutex zur synchronisation
 
** forkt dabei, nutzt pthread_mutex zur synchronisation
 
* [[newlib]], [[libc++]], libc++abi, compiler-rt, [[Clang]] mit LF OS Kenntnissen
 
* [[newlib]], [[libc++]], libc++abi, compiler-rt, [[Clang]] mit LF OS Kenntnissen
 +
* Bisschen Code der einigermaßen sinnvoll ist und sogar als Referenz hier im Wiki geeignet ist (und teilweise verlinkt)
  
  
 
[[Kategorie:Betriebssystem]]
 
[[Kategorie:Betriebssystem]]