Przyszłość już tu jest lub koduj bezpośrednio w przeglądarce

Opowiem Ci o zabawnej sytuacji, która mi się przydarzyła i o tym, jak zostać współtwórcą słynnego projektu.

Niedawno wpadłem na pomysł: uruchomienie Linuksa bezpośrednio z UEFI...
Pomysł nie jest nowy i istnieje wiele podręczników na ten temat. Możesz zobaczyć jeden z nich tutaj

Właściwie moje wieloletnie próby rozwiązania tego problemu doprowadziły do ​​jego całkowitego sformalizowania decyzja. Rozwiązanie jest całkiem działające i używam go na niektórych moich domowych komputerach. Rozwiązanie to opisano nieco szerzej. tutaj.

Istotą UEFI-Boot jest to, że partycja ESP (partycja systemowa EFI) jest połączona z katalogiem /boot. Te. wszystkie jądra i obrazy startowe (initrd) znajdują się na tej samej partycji, z której UEFI może uruchamiać pliki wykonywalne, a w szczególności uruchamiać programy ładujące system. Jednak samo jądro Linuksa w wielu dystrybucjach jest już zmontowane z opcją UEFISTUB, która umożliwia uruchomienie samego jądra z UEFI.

To rozwiązanie ma jeden nieprzyjemny moment - partycja ESP jest sformatowana w systemie FAT32, na którym nie można tworzyć twardych dowiązań (które system regularnie tworzy przy aktualizacji initrd). I nie ma w tym nic szczególnie kryminalnego, ale oglądanie ostrzeżeń systemowych podczas aktualizacji komponentów jądra nie jest zbyt przyjemne...

Jest inny sposób.

Menedżer rozruchu UEFI (ten sam, w którym należy zarejestrować program ładujący system operacyjny) może, oprócz programów ładujących/jąder Linuksa, także ładować sterowniki. Możesz więc załadować sterownik dla systemu plików, w którym masz /boot i załadować jądro bezpośrednio stamtąd za pomocą UEFI. Sterownik oczywiście trzeba umieścić na partycji ESP. Mniej więcej tak robią programy ładujące, takie jak GRUB. Ale najważniejsze jest to, że wszystkie często używane funkcje GRUB-a są już w UEFI. Dokładniej w menedżerze pobierania. A żeby było jeszcze nudniej, menedżer rozruchu UEFI ma w niektórych kwestiach jeszcze więcej możliwości.

Wydaje się, że to piękne rozwiązanie, jest jednak jedno „ALE” (a raczej było, ale o tym później). Faktem jest, że system sterowników UEFI jest dość prosty. Nie ma czegoś takiego jak zamontowanie systemu plików lub powiązanie sterownika z konkretnym urządzeniem. Istnieje wywołanie systemowe o umownej nazwie Map, które po kolei pobiera każdy sterownik i próbuje powiązać go ze wszystkimi, przynajmniej odpowiednimi urządzeniami. A jeśli kierowca był w stanie odebrać urządzenie, wówczas tworzone jest mapowanie – zapis połączenia. Dokładnie w ten sposób powinien zostać zainicjowany nowo załadowany sterownik na wspólnej stercie ze wszystkimi innymi. Wszystko, czego potrzebujesz, to ustawić jeden bit (LOAD_OPTION_FORCE_RECONNECT) na 1 w rekordzie rozruchowym sterownika, a UEFI wykona globalne ponowne mapowanie po załadowaniu.

Ale nie jest to takie łatwe. Standardowe narzędzie efibootmgr (które służy do konfiguracji menedżera odciążania UEFI) nie wie (a raczej nie wiedziało jak) ustawić ten bit. Musiałem zainstalować go ręcznie, wykonując dość skomplikowaną i niebezpieczną procedurę.

I po raz kolejny, próbując to zrobić rękami, nie mogłem tego znieść i sformalizowałem wydanie na GitHubie prosząc programistów o dodanie tej funkcji.

Minęło kilka dni, ale nikt nie zwrócił uwagi na moją prośbę. A z ciekawości zajrzałem do kodu źródłowego... rozwidliłem go i na kolanach wymyśliłem jak dodać tę funkcję... "Na kolanach", bo nic takiego nie instalowałem i edytowałem źródło kod bezpośrednio w przeglądarce.

Znam C (język programowania) bardzo powierzchownie, ale naszkicowałem przybliżone rozwiązanie (głównie kopiuj-wklej)... i wtedy pomyślałem - przynajmniej prawdopodobnie mam tam dużo błędów (moje wcześniejsze próby edycji cudzego Kod C został ukończony mniej więcej 10 raz) Wyślę żądanie ściągnięcia. Dobrze zaprojektowany.

I tam okazało się, że Travis CI był podłączony do sprawdzania żądań ściągnięcia. I pilnie opowiedział mi wszystkie moje błędy. Cóż, jeśli są znane błędy, nie ma potrzeby ich naprawiać: ponownie bezpośrednio w przeglądarce i za czwartą próbą kod zadziałał (dla mnie osiągnięcie).

I tak po prostu, nie wychodząc z przeglądarki, sformatowałem bardzo realne żądanie ściągnięcia w narzędzie używane w prawie wszystkich współczesnych dystrybucjach Linuksa.

Zaskoczył mnie fakt, że nie znając języka, niczego nie konfigurując (zależności wymagają sporo bibliotek do asemblera) i nawet nie uruchamiając kompilatora, po prostu „zakodowałem” w pełni działającą i użyteczną funkcję w przeglądarka .

Jednak moja prośba pozostała bez odpowiedzi od 19 marca 2019 r., a ja już zacząłem o niej zapominać.

Ale wczoraj to żądanie zostało dodane do mastera.

O czym więc jest moja historia? A mówi o tym, że w ramach nowoczesnych technologii okazało się, że prawdziwy kod można już pisać w przeglądarce, bez konieczności lokalnego wdrażania jakichkolwiek narzędzi programistycznych i zależności.

Co więcej, muszę przyznać, że jest to już mój drugi pull request dla dobrze znanych (przynajmniej w wąskich kręgach) narzędzi. Ostatnim razem moja prośba o poprawienie wyświetlania niektórych pól w interfejsie sieciowym SyncThing zaowocowała moją dosłownie jednowierszową edycją w środowisku, którego w ogóle nie znam.

W ankiecie mogą brać udział tylko zarejestrowani użytkownicy. Zaloguj się, Proszę.

Mam pisać więcej czy nie?

• tak

• nie warto

Głosowało 294 użytkowników. 138 użytkowników wstrzymało się od głosu.

Źródło: www.habr.com