Viitorul este deja aici sau codează direct în browser

Vă voi spune despre o situație amuzantă care mi s-a întâmplat și despre cum să devin colaborator la un proiect celebru.

Nu cu mult timp în urmă m-am chinuit cu o idee: pornirea Linux direct din UEFI...
Ideea nu este nouă și există o serie de manuale pe această temă. Puteți vedea unul dintre ei aici

De fapt, încercările mele de lungă durată de a rezolva această problemă au dus la o formalizare completă decizie. Soluția funcționează destul de mult și o folosesc pe unele dintre aparatele mele de acasă. Această soluție este descrisă puțin mai detaliat. aici.

Esența UEFI-Boot este că partiția ESP (EFI System Partition) este combinată cu directorul /boot. Acestea. toate nucleele și imaginile de bootstrap (initrd) sunt situate pe aceeași partiție de pe care UEFI poate lansa fișiere executabile și, în special, poate lansa încărcătoarele de sistem. Dar nucleul Linux în sine în multe distribuții este deja asamblat cu opțiunea UEFISTUB, care permite lansarea nucleului în sine de la UEFI.

Această soluție are un moment neplăcut - partiția ESP este formatată în FAT32, pe care este imposibil să se creeze linkuri hard (pe care sistemul le creează în mod regulat la actualizarea initrd-ului). Și nu este nimic deosebit de criminal în acest sens, dar a vedea avertismente de sistem la actualizarea componentelor kernelului nu este foarte plăcut...

Există o altă cale.

Managerul de boot UEFI (același în care trebuie să înregistrați bootloader-ul OS) poate, pe lângă încărcătoare/kernel-uri Linux, să încarce și drivere. Deci, puteți încărca driverul pentru sistemul de fișiere în care aveți /boot și încărcați nucleul direct de acolo folosind UEFI. Driverul, desigur, trebuie să fie plasat în partiția ESP. Acest lucru este aproximativ ceea ce fac încărcătoarele de boot precum GRUB. Dar punctul culminant este că toate funcțiile GRUB utilizate frecvent sunt deja în UEFI. Mai exact în managerul său de descărcare. Și pentru a fi și mai plictisitor, managerul de boot UEFI are și mai multe capacități în unele chestiuni.

Pare a fi o soluție frumoasă, dar există un „DAR” (sau mai degrabă, a fost, dar mai multe despre asta mai târziu). Faptul este că sistemul de driver UEFI este destul de simplu. Nu există așa ceva cum ar fi montarea unui sistem de fișiere sau asocierea unui driver cu un anumit dispozitiv. Există un apel de sistem cu numele convențional Map, care ia fiecare șofer pe rând și încearcă să îl asocieze cu toate, cel puțin dispozitivele potrivite. Și dacă șoferul a reușit să ridice dispozitivul, atunci se creează o mapare - o înregistrare de conectare. Acesta este exact modul în care driverul nou încărcat ar trebui să fie inițializat într-un heap comun cu toate celelalte. Și tot ce aveți nevoie este să setați un bit (LOAD_OPTION_FORCE_RECONNECT) la 1 în înregistrarea de pornire a driverului și UEFI va face această remapare globală după ce o încărcați.

Dar acest lucru nu este atât de ușor de făcut. Utilitarul standard efibootmgr (care este folosit pentru a configura managerul de descărcare UEFI) nu știe cum (sau mai degrabă, nu știa cum) să seteze acest bit. A trebuit să-l instalez manual printr-o procedură destul de complicată și periculoasă.

Și încă o dată, după ce am încercat să o fac cu mâinile mele, nu am putut suporta și am oficializat problemă pe GitHub solicitând dezvoltatorilor să adauge această caracteristică.

Au trecut câteva zile, dar nimeni nu a fost atent la cererea mea. Și de curiozitate, m-am uitat la codul sursă... L-am bifurcat și mi-am dat seama în genunchi cum să adaug această funcție... „În genunchi” pentru că nu am instalat așa ceva și am editat sursa cod direct în browser.

Cunosc C (limbajul de programare) foarte superficial, dar am schițat o soluție aproximativă (în mare parte copy-paste)... și apoi m-am gândit - cel puțin probabil că am o mulțime de erori acolo (încercările mele anterioare de a edita pe altcineva). Codul C au fost completați aproximativ pentru a 10-a oară) Voi emite o cerere de tragere. Bine proiectat.

Și acolo, Travis CI s-a dovedit a fi atașat să verifice cererile de retragere. Și mi-a spus cu sârguință toate greșelile mele. Ei bine, dacă există erori cunoscute, nu este nevoie să le reparăm: din nou, chiar în browser, iar la a patra încercare codul a funcționat (o realizare pentru mine).

Și exact așa, fără a părăsi browserul, am formatat un Pull Request foarte real într-un utilitar care este folosit în aproape toate distribuțiile Linux moderne.

Am fost surprins de faptul că, fără să cunosc limba cu adevărat, fără a configura nimic (dependențele necesită destul de multe biblioteci pentru asamblare) și fără să rulez vreodată compilatorul, am „codat” pur și simplu o caracteristică complet funcțională și utilă în browser.

Cu toate acestea, cererea mea a rămas fără răspuns din 19 martie 2019 și deja începusem să uit de ea.

Dar ieri această cerere a fost adăugată la master.

Deci despre ce este povestea mea? Și vorbește despre faptul că, în cadrul tehnologiilor moderne, s-a dovedit că codul real poate fi deja scris în browser, fără a implementa instrumente de dezvoltare și dependențe la nivel local.

Mai mult decât atât, trebuie să recunosc, aceasta este deja a doua mea cerere de pull pentru utilități binecunoscute (cel puțin în cercuri înguste). Ultima dată, solicitarea mea de a corecta afișarea unor câmpuri în interfața web SyncThing a dus la editarea mea literală pe o singură linie într-un mediu pe care nu îl cunosc deloc.

Numai utilizatorii înregistrați pot participa la sondaj. Loghează-te, Vă rog.

Ar trebui sa scriu mai mult sau nu?

  • da

  • nu merita

Au votat 294 de utilizatori. 138 utilizatori s-au abținut.

Sursa: www.habr.com

Adauga un comentariu