🥇Die Zukunft ist schon hier oder wir programmieren direkt im Browser

Ich möchte eine amüsante Anekdote erzählen, die mir widerfahren ist, und wie man ein Contributor in einem bekannten Projekt wird.

Vor nicht allzu langer Zeit habe ich mich mit einer Idee beschäftigt: das Laden von Linux direkt aus UEFI...
Die Idee ist nicht neu und es gibt einige Anleitungen zu diesem Thema. Eine davon ist hier verfügbar: hier

Meine langjährigen Versuche, dieses Problem zu lösen, mündeten in ein gut dokumentiertes Lösung. Die Lösung funktioniert einwandfrei und ich benutze sie auf einigen meiner Heimcomputer. Etwas ausführlicher ist diese Lösung beschrieben hier.

Die Essenz von UEFI-Boot besteht darin, dass die ESP (EFI System Partition) mit dem Verzeichnis /boot kombiniert wird. Das heißt, alle Kernel und die Initrd-Images werden auf genau dieser Partition gespeichert, von der UEFI ausführbare Dateien starten kann, einschließlich der Systemloader. Das Linux-Kernel selbst wird jedoch in vielen Distributionen mit der Option UEFISTUB kompiliert, die es dem Kernel ermöglicht, direkt aus UEFI zu starten.

Bei dieser Lösung gibt es einen unangenehmen Punkt – die ESP-Partition ist im FAT32-Format formatiert, was das Erstellen harter Links (die das System regelmäßig beim Aktualisieren von initrd erstellt) unmöglich macht. Das ist zwar nicht wirklich katastrophal, aber es ist nicht besonders angenehm, beim Aktualisieren von Kernel-Komponenten Warnungen vom System zu sehen...

Es gibt auch einen anderen Weg.

Der UEFI-Bootmanager (dort, wo der Betriebssystem-Loader eingetragen werden muss) kann neben den Bootloadern/Kernen von Linux auch Treiber laden. So kann der Treiber des Dateisystems, auf dem sich Ihr /boot befindet, geladen werden und von dort aus das Kernel über UEFI geladen werden. Der Treiber muss selbstverständlich in der ESP-Partition abgelegt werden. Genau das machen Bootloader wie GRUB. Das Besondere ist, dass alle häufig verwendeten Funktionen von GRUB bereits in UEFI vorhanden sind. Genauer gesagt in dessen Bootmanager. Und wenn man es noch eintöniger betrachten möchte, hat der UEFI-Bootmanager in bestimmten Aspekten sogar noch mehr Möglichkeiten.

Es scheint eine ansprechende Lösung zu sein, aber es gibt ein "ABER" (genauer gesagt gab es eins, aber dazu später mehr). Die UEFI-Treiberarchitektur ist ziemlich unaufwendig. Es gibt kein Konzept wie das Einbinden eines Dateisystems oder das Verknüpfen eines Treibers mit einem bestimmten Gerät. Stattdessen gibt es einen Systemaufruf mit dem bedingten Namen Map, der nacheinander jeden Treiber nimmt und versucht, ihn mit allen geeigneten Geräten zu verknüpfen. Wenn ein Treiber erfolgreich ein Gerät erkennt, wird ein Mapping – ein Verknüpfungseintrag – erstellt. So sollte der neu geladene Treiber in der allgemeinen Ansammlung aller anderen konfiguriert werden. Und alles, was dafür erforderlich ist, ist, im Boot-Eintrag des Treibers ein Bit (LOAD_OPTION_FORCE_RECONNECT) auf 1 zu setzen, und UEFI wird nach dem Laden dieses Treibers das globale Remapping durchführen.

Aber das zu bewerkstelligen ist gar nicht so einfach. Das Standard-Tool efibootmgr, mit dem der UEFI-Boot-Manager konfiguriert wird, konnte (genauer gesagt konnte es früher nicht) dieses Bit setzen. Man musste es manuell durch ein ziemlich kompliziertes und riskantes Verfahren setzen.

Und so habe ich es nach einem erneuten Versuch, dies manuell zu tun, nicht mehr ausgehalten und beschlossen, Problem auf GitHub mit der Bitte an die Entwickler, diese Funktion hinzuzufügen.

Einige Tage sind vergangen, aber niemand hat auf meine Anfrage reagiert. Aus Neugier habe ich mir die Quellcodes angesehen… habe geforkt und mir überlegt, wie ich diese Funktion "im Handumdrehen" hinzufügen könnte… "im Handumdrehen", weil ich nichts wie ein eigenes Setup eingerichtet habe und die Quellcodes direkt im Browser bearbeitet habe.

C (Programmiersprache) kenne ich nur oberflächlich, aber ich habe eine grobe Lösung skizziert (hauptsächlich durch Copy-Paste)… und dann dachte ich — ich habe da wahrscheinlich eine Menge Fehler (meine früheren Versuche, den Code anderer in C zu ändern, benötigten etwa zehn Anläufe), also werde ich einen Pull Request erstellen. Nun ja, habe ich das gemacht..

Dabei stellte ich fest, dass Travis CI zur Überprüfung der Pull Requests eingebunden war. Es hat mir alle meine Fehler sorgfältig angezeigt. Wenn die Fehler bekannt sind — warum nicht gleich beheben: wieder direkt im Browser, und beim vierten Versuch konnte der Code kompiliert werden (eine Errungenschaft für mich).

So habe ich, ohne den Browser zu verlassen, einen echten Pull Request für ein Werkzeug erstellt, das in fast allen modernen Linux-Distributionen verwendet wird.

Es hat mich selbst überrascht, dass ich, trotz meiner mangelnden Sprachkenntnisse und ohne irgendwelche Einstellungen (dort benötigt man einige Bibliotheken für die Kompilierung), noch nie den Compiler ausgeführt habe, einfach im Browser eine ziemlich funktionale und nützliche Funktion „programmiert“ habe.

Jedoch hing mein Request seit dem 19. März 2019 ohne Reaktion, und ich hatte bereits begonnen, ihn zu vergessen.

Doch gestern wurde dieser Request in den Master hinzugefügt.

Worüber handelt also mein Bericht? Er handelt davon, dass man mit modernen Technologien tatsächlich echten Code im Browser schreiben kann, ohne lokal irgendwelche Entwicklerwerkzeuge oder Abhängigkeiten zu installieren.

Übrigens muss ich zugeben, dass es bereits mein zweiter Pull-Request in bekannte (zumindest in engen Kreisen) Utilities ist. Das letzte Mal hat meine Bitte, die Darstellung einiger Felder im Web-Interface von SyncThing zu korrigieren, in einer buchstäblich einzeiligen Änderung in einer Umgebung resultiert, die ich überhaupt nicht kenne.

Nur registrierte Benutzer können an der Umfrage teilnehmen. Bitte melden Sie sich an.Sind Sie an Contour interessiert?