Das Haiku Projekt hat seinen monatlichen Bericht für den Monat November veröffentlicht. Dieses Mal ist er eher kurz, doch die einzelnen Änderungen sind teilweise sehr bedeutend. Highlights sind NTFS und der Intel Grafiktreiber.
Der Treiber für das Windows-Dateisystem NTFS basiert jetzt auf der neuesten NTFS-3g Version und der Verbindungscode zwischen NTFS-3g und dem Haiku Kernel wurde neu geschrieben. Der alte Verbindungscode stammt noch von BeOS und wurde teilweise für Haiku umgeschrieben. Jetzt ist der Code ähnlich aufgebaut, wie bei anderen Dateisystemen und ist sauberer. Dadurch konnten auch Fehler an anderen Stellen im Treiber gefunden und behoben werden.
Ausserdem wurde der Treiber für das FAT Dateisystem optimiert und einige nicht benötigte Locks entfernt. Weiter wurden alle verbliebenen Nennungen von OpenBeOS im Quellcode zu Haiku geändert und der UDP Socket Code wurde aufgeräumt. Der LGTM Scan wurde aktualisiert und einige Fehler behoben, die er gefunden hat.
Die vielleicht wichtigste Änderung diesen Monat ist die weiter andauernde Arbeit am Grafiktreiber intel_extreme, der für die meisten Intel Grafikeinheiten zuständig ist. Damit werden jetzt auch Chips der Generationen Haswell, Skylake, Coffeelake und Kabylake unterstützt. Es wurden auch viele Probleme mit bereits vorher unterstützten Geräten behoben und der Helligkeitsregler wird nur noch bei eingebauten Displays angezeigt, da die Helligkeit von externen Bildschirmen nicht beeinflusst werden kann.
Es wurden Escape Sequenzen implementiert, mit denen Terminalprogramme die Cursorfarbe auslesen und festlegen können und um andere Farben für verschiedene Farbschemas zu definieren. Ausserdem wurde der Code optimiert, der fehlgeschlagene Paketdownloads wiederholt, sodass beschädigte Downloads nicht mehr den Download der korrekten Datei blockieren.
Des Weiteren wurde CPUID leaf 0x1f implementiert. CPUID ist eine Instruktion, mit der Programme die verfügbaren Funktionen der CPU ermitteln können. Es wird regelmässig aktualisiert, wenn neue Befehlssätze hinzugefügt werden, also muss Haiku diese Änderungen regelmässig übernehmen, um weiterhin die korrekten Funktionen über seine APIs aufzulisten. Ausserdem wurden Informationen über die CPU Frequenz zu cpu_info hinzugefügt. Diese Information war bereits im Kernel, aber wurde nicht an den Userspace weitergegeben.
Für NVMe SSDs wurde die Trim Funktion eingebaut. Mit dem fstrim Befehl kann man die SSD jetzt darüber informieren, wenn bestimmte Sektoren nicht mehr gebraucht werden, sodass diese für eine gleichmässige Abnutzung mitverwendet werden können. Weiter wurde die ConditionVariable Implementation im Kernel überarbeitet, um den Code zu vereinfachen und einen Fehler zu beheben, der manchmal Kernel Panics auslöste.
Die Jamfile Engine wurde jetzt in ein eigenes Repository verschoben. Dabei handelt es sich um ein Build System auf Basis von Jam, mit dem auch Haiku selbst kompiliert wird. Es ist eine Alternative zur Makefile Engine, mit der viel Drittanbietersoftware für Haiku kompiliert wird. Sie ist durch diese Änderung jetzt im Haiku Depot verfügbar und muss nicht mehr von Hand aus dem Haiku Quellcode entnommen werden. Die Jamfile Engine ist hilfreich, wenn man ein Programm mit Jam anstatt mit Make kompilieren will.
Ausserdem wurde damit begonnen, Haiku mit der neueren GCC Version 11 zu kompilieren. Bisher wird GCC Version 8 eingesetzt. Die Umstellung erfordert einige Änderungen am Code, da neue Warnungen entstanden sind und mancher Code nicht mehr erfolgreich kompiliert wird. Es müssen auch einige Stellen debuggt werden, an denen neue Optimierungen in GCC dafür sorgen, dass Code nicht mehr wie vorgesehen funktioniert.
Besonders viel wurde diesen Monat auch an den Portierungen auf andere CPU Architekturen gearbeitet. Am PowerPC Port wurden minimale Fehler behoben, sodass er weiterhin kompiliert werden kann. Der RISC-V Code wurde aufgeräumt und ein paar kleine Fehler wurden darin behoben. Eine funktionierende Version für ARM scheint immer näher zu rücken.
Es gibt viel Fortschritt beim 32Bit ARM Port mit EFI als Bootmethode. Vorherige Versuche, einen ARM Port zu erstellen, nutzten die Bootmethode von Linux, wo der Firmware Bootloader (meistens uboot) nur minimale Schritte für den Startvorgang erledigt und dann die Kontrolle komplett an das Betriebssystem übergibt. Der Linux Kernel ist dafür gemacht, auf diese Art zu funktionieren, aber Haiku ist stärker von der Firmware abhängig, um den Stage 2 Bootloader anzeigen zu können, der ein benutzerfreundliches Boot Menü bietet.
Mit dem alten u-boot System musste hardwarespezifischer Code für jedes neue ARM Gerät geschrieben werden und der Bootloader enthielt sehr viel hardwarespezifischen Code. EFI löst das Problem. Bei der EFI Bootmethode werden Befehle an u-boot oder andere EFI Implementierungen gesendet und diese erledigen die hardwarespezifischen Aufgaben. Damit kann auch der Code der x86 und RISC-V Ports wiederverwendet werden, die auf die gleiche Art starten.
Nachdem die Bootloader Probleme behoben sind, wird es jetzt viel einfacher, die frühen Schritte des Kernelstarts zu untersuchen, was schon zu vielen Verbesserungen beim MMU Treiber und der FDT Hardware Discovery geführt hat.
Auch am 64Bit ARM (aarch64) Port wurde gearbeitet. Hier wurden Probleme im Code der Math Bibliothek behoben und einige Compiler Flags optimiert.
Ganz neu wird jetzt auch an einem 32Bit x86 EFI Bootloader gearbeitet. Bis jetzt konnte nur die 64Bit Version mit EFI starten und brauchte dazu auch ein 64Bit EFI BIOS, während die 32Bit x86 Version von Haiku nur im Legacy BIOS Modus gestartet werden konnte. Einige Geräte haben aber keine Legacy Boot Option mehr, obwohl sie noch mit 32Bit CPU ausgestattet sind oder eine 64Bit CPU, aber nur ein 32Bit EFI haben. Diese Geräte konnten bislang nicht mit Haiku genutzt werden, der neue 32Bit EFI Bootloader wird es aber demnächst möglich machen.
Quelle: https://www.haiku-os.org/blog/pulkomandy/2021-12-02-haiku_activity_report_november_2021/
