🥇Przyszłość jest już tutaj, czyli kodujemy bezpośrednio w przeglądarce

Opowiem o zabawnym incydencie, który mi się przydarzył, i jak zostać współautorem w znanym projekcie.

Niedawno zajmowałem się pewnym pomysłem: uruchamianiem Linuxa bezpośrednio z UEFI...
Pomysł nie jest nowy i istnieje pewna liczba przewodników na ten temat. Jeden z nich można zobaczyć tutaj

Właściwie moje długie próby rozwiązania tego problemu przerodziły się w dobrze zorganizowane decyzję. Rozwiązanie jest całkowicie funkcjonalne i stosuję je na części moich domowych komputerów. Nieco dokładniej to rozwiązanie opisano tutaj.

Istota UEFI-Boot polega na tym, że ESP (EFI System Partition) jest połączona z katalogiem /boot. To znaczy, że wszystkie jądra i obrazy początkowego uruchamiania (initrd) są umieszczane w tym samym wydzielonym obszarze, z którego UEFI może uruchamiać pliki wykonywalne, a w szczególności uruchamiać bootloadery systemu. Jednak samo jądro Linuxa w już wielu dystrybucjach jest kompilowane z opcją UEFISTUB, która pozwala zainicjować jądro z UEFI.

To rozwiązanie ma jeden nieprzyjemny aspekt — partycja ESP jest sformatowana jako FAT32, na której nie można tworzyć twardych linków (które system regularnie tworzy podczas aktualizacji initrd). I nic szczególnie złego w tym nie ma, ale nie jest miło widzieć ostrzeżenia systemu przy aktualizacjach komponentów jądra...

Istnieje też inna droga.

Menadżer rozruchu UEFI (ten, w którym trzeba wpisać bootloader OS) potrafi oprócz bootloaderów/jąder Linuxa ładować również sterowniki. Tak więc można załadować sterownik do systemu plików, w którym masz /boot, i bezpośrednio stamtąd ładować jądro za pomocą UEFI. Oczywiście, sterownik trzeba umieścić w partycji ESP. Właśnie tym zajmują się bootloadery typu GRUB. Ale smaczek polega na tym, że wszystkie często używane funkcje GRUB już są w UEFI. A mówiąc jeszcze bardziej szczegółowo, menadżer rozruchu UEFI ma nawet więcej możliwości w niektórych kwestiach.

Wydawałoby się, że to ładne rozwiązanie, ale jest jedno "ALE" (a raczej było, ale o tym później). Chodzi o to, że system sterowników UEFI jest zbudowany dość prosto. Nie ma tam pojęcia takiego jak montowanie systemu plików czy wiązanie sterownika z konkretnym urządzeniem. Jest tam wywołanie systemowe o warunkowej nazwie Map, które po kolei bierze każdy sterownik i próbuje powiązać go ze wszystkimi, w miarę odpowiednimi urządzeniami. I jeśli sterownik udało się połączyć z urządzeniem, to tworzy się mapowanie — powiązanie. Właśnie tak w ogólnej masie z wszystkimi innymi powinien być inicjowany nowo załadowany sterownik. I to wszystko, co trzeba zrobić — w zapisie rozruchowym sterownika ustawić jeden bit (LOAD_OPTION_FORCE_RECONNECT) na 1, a UEFI po jego załadowaniu zrobi ten globalny remap.

Tylko że zrobienie tego nie jest takie proste. Standardowe narzędzie efibootmgr (za pomocą którego konfiguruje się menedżera rozruchu UEFI) nie potrafi (właściwie nie potrafiło) ustawiać tego bitu. Musiałem ustawiać go ręcznie przez dość skomplikowaną i niebezpieczną procedurę.

I znów próbując to zrobić ręcznie, nie wytrzymałem i stworzyłem zgłoszenie na GitHubie z prośbą do programistów o dodanie tej możliwości.

Minęło kilka dni, ale nikt nie zwrócił uwagi na moją prośbę. Z ciekawości zerknąłem na źródła… stworzyłem fork i zastanowiłem się, jak tę funkcję dodać "na kolanie"… "Na kolanie", ponieważ niczego takiego sobie nie instalowałem i edytowałem źródła bezpośrednio w przeglądarce.

C (język programowania) wiem bardzo powierzchownie, ale mniej więcej skonstruowałem rozwiązanie (głównie kopiując i wklejając)… a potem pomyślałem — a chociaż na pewno mam tam pełno błędów (moje wcześniejsze próby poprawy cudzego kodu C składały się ze dziesiątego podejścia), stworzę Pull Request. No i stworzyłem.

A tam okazało się, że zainstalowano Travis CI do weryfikacji pull requestów. I on starannie wyświetlił mi wszystkie moje błędy. Cóż, jeśli błędy są znane — czemu ich nie poprawić: znów bezpośrednio w przeglądarce, i przy czwartej próbie kod się skompilował (osiągnięcie dla mnie).

I tak, nie wychodząc z przeglądarki, stworzyłem całkiem realny Pull Request do narzędzia, z którego korzystają praktycznie wszystkie nowoczesne dystrybucje Linuxa.

Zdziwiło mnie to, że nie znając języka, bez żadnych ustawień (potrzebny jest spory zestaw bibliotek do kompilacji) i nawet nie uruchamiając kompilatora, po prostu w przeglądarce "napisałem" całkiem działającą i użyteczną funkcję.

Jednakże mój wniosek wisiał bez reakcji od 19 marca 2019 roku, a ja już zacząłem o nim zapominać.

Ale wczoraj ten wniosek został dodany do master.

Cóż, o czym jest moja opowieść. Jest ona o tym, że w ramach nowoczesnych technologii okazało się, że prawdziwy kod można już pisać w przeglądarce, nie instalując lokalnie żadnych narzędzi deweloperskich ani zależności.

Trzeba przyznać, że to już mój drugi pull request w znane (przynajmniej w wąskich kręgach) narzędzia. Poprzednio moja prośba o poprawienie wyświetlania niektórych pól w interfejsie webowym SyncThing zakończyła się moją dosłownie jednoliniową poprawką w środowisku, którego zupełnie nie znałem.

Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. Zaloguj się, proszę.