Vi cuntaraghju di una situazione divertente chì m'hà accadutu, è cumu diventà un cuntributore à un prughjettu famosu.
Pocu pocu fà, stava à fà una idea: avvià Linux direttamente da UEFI ...
L'idea ùn hè micca nova è ci sò una quantità di manuali nantu à questu tema. Pudete vede unu di elli
In verità, i mo tentativi di longu tempu di risolve stu prublema anu risultatu in una formalizazione cumpleta . A suluzione hè abbastanza funzionante è l'aghju utilizatu in alcune di e mo macchine di casa. Sta suluzione hè descritta in un pocu più di dettu. .
L'essenza di UEFI-Boot hè chì a partizione ESP (EFI System Partition) hè cumminata cù u cartulare /boot. Quelli. tutti i kernels è l'imaghjini di bootstrap (initrd) sò situati nantu à a listessa partizione da quale UEFI pò lancià i fugliali eseguibili è, in particulare, lancià i caricatori di u sistema. Ma u kernel Linux stessu in parechje distribuzioni hè digià assemblatu cù l'opzione UEFISTUB, chì permette chì u kernel stessu sia lanciatu da UEFI.
Sta suluzione hà un mumentu dispiacevule - a partizione ESP hè furmatu in FAT32, nantu à quale hè impussibile di creà ligami duri (chì u sistema crea regularmente quandu aghjurnà l'initrd). È ùn ci hè nunda di particularmenti criminali in questu, ma vede avvisi di u sistema quandu aghjurnà i cumpunenti di u kernel ùn hè micca assai piacevule ...
Ci hè un altru modu.
U gestore di boot UEFI (u stessu induve avete bisognu di registrà u bootloader di l'OS) pò, in più di bootloaders / kernels Linux, carricà ancu i drivers. Allora pudete carricà u driver per u sistema di fugliale induve avete / boot è carica u kernel direttamente da quì cù UEFI. U cunduttore, sicuru, deve esse piazzatu in a partizione ESP. Questu hè circa ciò chì facenu i bootloaders cum'è GRUB. Ma u puntu culminante hè chì tutte e funzioni GRUB spessu usate sò digià in UEFI. Più precisamente in u so gestore di download. È per esse ancu più noioso, u gestore di boot UEFI hà ancu più capacità in certi affari.
Sembra esse una bella suluzione, ma ci hè un "MA" (o megliu, era, ma più nantu à questu dopu). U fattu hè chì u sistema di driver UEFI hè abbastanza simplice. Ùn ci hè nunda di muntà un sistema di fugliale o associà un driver cù un dispositivu specificu. Ci hè una chjama di u sistema cù u nome cunvinziunali Mappa, chì piglia ogni cunduttore in turnu è prova di associà cù tutti, almenu i dispositi adattati. È se u cunduttore hà sappiutu ripiglià u dispusitivu, allora una mappa hè creata - un registru di cunnessione. Questu hè esattamente cumu u driver di novu caricatu deve esse inizializatu in un cumunu cumunu cù tutti l'altri. È tuttu ciò chì avete bisognu hè di stabilisce un bit (LOAD_OPTION_FORCE_RECONNECT) à 1 in u registru di boot di u driver è UEFI farà sta remappa globale dopu a carica.
Ma questu ùn hè micca cusì faciule da fà. L'utilità standard efibootmgr (chì hè aduprata per cunfigurà u gestore di scaricamentu UEFI) ùn sapi micca cumu (o megliu, ùn sapia micca) per stabilisce stu bit. Aviu avutu à stallà manualmente attraversu una prucedura piuttostu cumplicata è periculosa.
È una volta, dopu avè pruvatu à fà cù e mo mani, ùn pudia micca stà è formalizatu dumandendu à i sviluppatori di aghjunghje sta funzione.
Passanu parechji ghjorni, ma nimu hà fattu attente à a mo dumanda. E per curiosità, aghju guardatu u codice fonte ... L'aghju forked, è hà capitu nantu à i mo ghjinochje cumu aghjunghje sta funzione ... "In ghjinochje" perchè ùn aghju micca installatu nunda cusì è editatu a fonte. codice direttamente in u navigatore.
Cunnoscu C (u linguaghju di prugrammazione) assai superficialmente, ma aghju abbozzatu una soluzione apprussimata (principalmente copia-incolla) ... è dopu aghju pensatu - almenu probabilmente aghju assai errori quì (i mo passati tentativi di edità di qualcunu altru). U codice C sò stati cumpletati circa a 10ª volta) Emette una Pull Request. Ebbè .
È quì Travis CI hè statu attaccatu per verificà e richieste di pull. È m'hà dettu diligentemente tutti i mo sbagli. Ebbè, s'ellu ci sò errori cunnisciuti, ùn ci hè bisognu di riparà: di novu, ghjustu in u navigatore, è in u quartu tentativu u codice hà travagliatu (un successu per mè).
È cusì, senza abbandunà u navigatore, aghju furmatu una Pull Request assai vera in una utilità chì hè utilizata in quasi tutte e distribuzioni Linux muderni.
Eru sorpresu da u fattu chì, senza cunnosce veramente a lingua, senza stabilisce nunda (i dipendenze necessitanu uni pochi di biblioteche per l'assemblea), è senza mai ancu eseguisce u compilatore, aghju solu "codificatu" una funzione cumpletamente funzionante è utile in u navigatore.
Tuttavia, a mo dumanda ùn hà micca rispostu dapoi u 19 di marzu di u 2019, è aghju digià cuminciatu à scurdà di questu.
Ma ieri sta dumanda hè stata aghjunta à u maestru.
Allora chì hè a mo storia? È si parla di u fattu chì, in u quadru di tecnulugii muderni, s'hè risultatu chì u codice veru pò esse digià scrittu in u navigatore, senza implementà alcunu strumenti di sviluppu è dipendenze in u locu.
Inoltre, devu ammette, questu hè digià a mo seconda dumanda di pull per l'utilità ben cunnisciuta (almenu in cerchi stretti). L'ultima volta, a mo dumanda per correggerà a visualizazione di certi campi in l'interfaccia web SyncThing hà risultatu in a mo edita literalmente in una linea in un ambiente chì ùn cunnoscu micca.
Solu l'utilizatori registrati ponu participà à l'indagine. , per piacè.
Deve scrive più o micca ?
-
sì
-
micca i bisognu
294 utilizatori anu vutatu. 138 utilizatori si sò astenuti.
Source: www.habr.com