Mesélek egy vicces szituációról, ami megtörtént velem, és arról, hogyan válhatok közreműködővé egy híres projektben.
Nem sokkal ezelőtt egy ötleten töprengtem: indítsam el a Linuxot közvetlenül az UEFI-ről...
Az ötlet nem új, és számos kézikönyv létezik ebben a témában. Az egyiket láthatod
Valójában a probléma megoldására irányuló régóta tartó próbálkozásaim egy teljesen formalizált megoldást eredményeztek . A megoldás nagyon működik, és néhány otthoni gépemen használom. Ezt a megoldást egy kicsit részletesebben ismertetjük. .
Az UEFI-Boot lényege, hogy az ESP (EFI System Partition) partíció kombinálva van a /boot könyvtárral. Azok. minden kernel és rendszerindító lemezkép (initrd) ugyanazon a partíción található, ahonnan az UEFI futtatható fájlokat és különösen rendszerindító betöltőket tud elindítani. De maga a Linux kernel sok disztribúcióban már össze van szerelve az UEFISTUB opcióval, amely lehetővé teszi magának a kernelnek az UEFI-ről történő indítását.
Ennek a megoldásnak van egy kellemetlen pillanata - az ESP partíció FAT32-ben van formázva, amelyen lehetetlen kemény hivatkozásokat létrehozni (amit a rendszer rendszeresen létrehoz az initrd frissítésekor). És ebben nincs semmi különösebb bűnöző, de rendszerfigyelmeztetéseket látni a kernelkomponensek frissítésekor nem túl kellemes...
Van más mód is.
Az UEFI boot manager (ugyanaz, ahol regisztrálni kell az operációs rendszer rendszerbetöltőjét) a rendszerbetöltők/Linux kernelek mellett illesztőprogramokat is betölthet. Tehát betöltheti annak a fájlrendszernek az illesztőprogramját, ahol a /boot van, és onnan közvetlenül betöltheti a kernelt UEFI segítségével. Az illesztőprogramot természetesen az ESP partícióba kell helyezni. Nagyjából ezt teszik az olyan rendszerbetöltők, mint a GRUB. A legfontosabb azonban az, hogy az összes gyakran használt GRUB-funkció már az UEFI-ben található. Pontosabban a letöltéskezelőjében. És hogy még unalmasabb legyen, az UEFI rendszerindítás-kezelő bizonyos kérdésekben még több képességgel rendelkezik.
Szép megoldásnak tűnik, de van egy „DE” (vagy inkább az volt, de erről majd később). Az a tény, hogy az UEFI illesztőprogram-rendszer meglehetősen egyszerű. Nincs olyan, hogy fájlrendszert kell csatlakoztatni vagy illesztőprogramot társítani egy adott eszközhöz. Van egy rendszerhívás a hagyományos Map néven, amely sorra veszi az egyes illesztőprogramokat, és megpróbálja társítani az összes, legalábbis megfelelő eszközzel. És ha az illesztőprogram fel tudta venni az eszközt, akkor létrejön egy leképezés - egy összekötő rekord. Pontosan így kell az újonnan betöltött illesztőprogramot inicializálni egy közös kupacban az összes többivel. És mindössze annyit kell tennie, hogy egy bitet (LOAD_OPTION_FORCE_RECONNECT) 1-re kell állítani az illesztőprogram indító rekordjában, és az UEFI elvégzi ezt a globális újraleképezést a betöltés után.
De ezt nem olyan könnyű megtenni. A szabványos efibootmgr segédprogram (amely az UEFI offload manager konfigurálására szolgál) nem tudja, hogyan (vagy inkább nem tudta, hogyan) kell beállítani ezt a bitet. Egy meglehetősen bonyolult és veszélyes eljárás során manuálisan kellett telepítenem.
És még egyszer, miután a kezemmel próbáltam megcsinálni, nem bírtam, és hivatalossá tettem megkérve a fejlesztőket, hogy adják hozzá ezt a funkciót.
Eltelt néhány nap, de senki nem figyelt a kérésemre. És kíváncsiságból megnéztem a forráskódot... Elvillantottam, és térden kitaláltam, hogyan kell hozzáadni ezt a funkciót... „Térdre állva”, mert nem telepítettem ilyesmit és szerkesztettem a forrást kódot közvetlenül a böngészőben.
A C-t (a programozási nyelvet) nagyon felületesen ismerem, de felvázoltam egy hozzávetőleges megoldást (leginkább másolás-beillesztés)... aztán arra gondoltam - legalábbis valószínűleg sok hiba van benne (múltbeli próbálkozásaim szerkeszteni valaki másét A C kód körülbelül 10. alkalommal készült el) Pull Request-et adok ki. Jól .
És ott kiderült, hogy a Travis CI-t csatolták a lehívási kérések ellenőrzéséhez. És szorgalmasan elmondta minden hibámat. Nos, ha vannak ismert hibák, akkor nem kell javítani: ismét közvetlenül a böngészőben, és a negyedik próbálkozásra a kód működött (számomra teljesítmény).
És pont így, anélkül, hogy elhagytam volna a böngészőt, egy nagyon valós Pull Request-et formáztam egy olyan segédprogramba, amelyet szinte minden modern Linux disztribúció használ.
Meglepett, hogy anélkül, hogy igazán tudtam volna a nyelvet, anélkül, hogy bármit beállítottam volna (a függőségek jó néhány könyvtárat igényelnek az összeállításhoz), és anélkül, hogy a fordítót valaha is futtattam volna, egyszerűen "kódoltam" egy teljesen működő és hasznos funkciót a böngésző .
A kérésem azonban 19. március 2019-e óta nem reagált, és már kezdtem megfeledkezni róla.
De tegnap ezt a kérést hozzáadták a mesterhez.
Szóval miről szól a történetem? És arról beszél, hogy a modern technológiák keretein belül kiderült, hogy már a böngészőben is lehet valódi kódot írni anélkül, hogy bármilyen fejlesztőeszközt és függőséget helyben telepítenénk.
Sőt, bevallom, ez már a második húzókérésem a jól ismert (legalábbis szűk körökben) közművek felé. Múltkor a SyncThing webes felületén néhány mező megjelenítésének javítására irányuló kérésem szó szerint egysoros szerkesztésemet eredményezett egy olyan környezetben, amelyet egyáltalán nem ismerek.
A felmérésben csak regisztrált felhasználók vehetnek részt. , kérem.
Írjak többet vagy ne?
-
igen
-
nem éri meg
294 felhasználó szavazott. 138 felhasználó tartózkodott.
Forrás: will.com