Michael Lotz, momentan Haiku-Vollzeitentwickler, hat einen weiteren Bericht über seine Arbeit geschrieben.
Wie in den Wochen zuvor, war er nochmal total im "Kernelmode" und spürte einigen tief im System versteckten Bugs hinterher. Dabei arbeitete er an einer Erweiterung des Interrupt Routing Codes, was hoffentlich Ticket #8111 lösen wird. Um der Ursache für Ticket #8085 auf die Spur zu kommen, beschäftigte er sich nochmal etwas ausführlicher mit dem Umgang mit "USB Legacy", konnte allerdings trotzdem nicht herausfinden was an Haikus Implementierung falsch sein könnte.
An dieser Stelle bittet Michael inständig Tickets im Bugtracker aufzugeben. Nur so können die Entwickler überhaupt von Problemen erfahren und an Lösungen arbeiten. Insbesondere kritische Fehler, die ein Booten des Systems verhindern, treten oft nur bei bestimmten Hardwarekonfigurationen auf und können daher von jemanden der nicht die gleiche Hardware hat nicht mal erahnt werden.
Ein Beispiel für so einen Fall ist Ticket #8153, welches einzig mit den dort hinterlegten Informationen gelöst werden konnte.
Um Problemen nachspüren zu können die nur bei längerer Laufzeit auftreten, hat sich Michael einen Zweitrechner aufgebaut, damit er nebenher produktiv weiterarbeiten kann. Hier laufen z.B. auch Ermittlungen zu Ticket #7889, bei dem immer wieder ganze Audio CDs ausgelesen werden müssen.
Auf dem Zweitrechner fand auch eine bereits erfolgreiche Detektivarbeit statt, die das Ticket #8068 lösen sollte, ein Bug der den app_server abschießt. Michael stieß bereits selbst auf diesen Crash während er am Treiber für die Sandybridge-Grafik bastelte. Er tritt nur unter VESA auf und, wie sich herausstellte, nur bei Multi-CPU Maschinen. Außerdem schien der app_servers nur Opfer zu sein und nicht der eigentliche Auslöser des Crashs. Ein Skript, das ständig die Auflösung wechselt, konnte den Crash beliebig reproduzieren.
Die Fährte führte zum vm86 Code, der als virtueller 8086 Mode gestattet VESA BIOS Aufrufe zu benutzen. Nachdem er sich etwas in den vm86 Code eingearbeitet hatte, wurde ihm klar, dass Code zum Interrupthandling bei den letzten Änderungen nicht aktualisiert wurde. Leider stellte sich raus, dass zumindest dieser Bug nicht daran lag.
Da der Crash nicht bei Einzel-CPU Maschinen auftrat und der virtuelle 8086 Mode generell nicht anfällig für Thread-Scheduling ist, musste das Problem beim Verlassen des 8086 Modes liegen. Wie Michael herausfand, wird dabei nicht alles wieder so hergestellt, wie es vor dem Eintritt in den 8086 Modus war. So wurde auch das %fs Register wieder hergestellt, das Haiku für den CPU-spezifischen Thread Local Storage (TLS) (eine Art Thread-gebundener Speicher) verwendet. Das geht solange gut, bis der Thread der den Mode-Wechsel macht durch den Scheduler auf eine andere CPU gewechselt wird während er sich noch im 8086 Modus befindet. Beim Wechsel zurück in den User-Modus stürzt dann der nächste ab, der TLS benutzt.
Der eigentliche Fix für den Bug waren dann nur wenige geänderte Zeilen im Programmcode.
Das zeigt mal wieder, was für große Auswirkungen kleine Änderungen haben können. Und wie wenig der Umfang eines Code-Commits den dahinter stehenden Aufwand wiederspiegeln.
Am Ende seines Blogs kündigt Michael seine Pläne für die nächste Zukunft an: Es geht wieder zurück zum Funknetzwerk. Allerdings nicht um Wifi selbst oder dessen Verschlüsselung; das ist bereits funktionsfähig. Ihm geht es um die Alltagstauglichkeit, und das ist in erster Linie die automatische Anmeldung an Netzwerken ohne ständige Passworteingabe.
Dazu wird er eine API zum Verwalten und sicheren Speichern von Passwörtern, Schlüsseln und Zertifikaten verallgemeinern und implementieren, die Axel Dörfler vor einiger Zeit mal geplant hat. Diese wird dann systemweit zur Verfügung stehen und kann auch von anderen Anwendungen genutzt werden. Davon könnte beispielsweise WebPositive profitieren, um die Logins zu diversen Webseiten zu verwalten.
Keine Kommentare:
Kommentar veröffentlichen