Ik sil jo fertelle oer in grappige situaasje dy't my barde, en hoe't jo in meiwurker wurde kinne oan in ferneamd projekt.
Net lang lyn wie ik oan it tinken mei in idee: Linux direkt opstarte fan UEFI ...
It idee is net nij en d'r binne in oantal hânboeken oer dit ûnderwerp. Jo kinne ien fan har sjen
Eins resultearre myn langsteande besykjen om dit probleem op te lossen yn in folslein formalisearre . De oplossing wurket frijwat en ik brûk it op guon fan myn thúsmasines. Dizze oplossing wurdt beskreaun yn in bytsje mear detail. .
De essinsje fan UEFI-Boot is dat de partition ESP (EFI System Partition) wurdt kombineare mei de /boot-map. Dy. alle kernels en bootstrap-ôfbyldings (initrd) lizze op deselde partysje wêrfan UEFI útfierbere bestannen kin starte en, yn it bysûnder, systeembootladers starte. Mar de Linux kernel sels yn in protte distribúsjes is al gearstald mei de UEFISTUB-opsje, wêrtroch de kernel sels kin wurde lansearre fan UEFI.
Dizze oplossing hat ien onaangenaam momint - de ESP-partysje is opmakke yn FAT32, wêrop it ûnmooglik is om hurde keppelings te meitsjen (dy't it systeem regelmjittich makket by it bywurkjen fan de initrd). En d'r is neat spesjaal krimineel oer dit, mar it sjen fan systeemwarskôgingen by it bywurkjen fan kernelkomponinten is net heul noflik ...
Der is in oare manier.
De UEFI-bootbehearder (deselde wêr't jo de OS-bootloader moatte registrearje) kin, neist bootloaders/Linux-kernels, ek stjoerprogramma's laden. Sa kinne jo de stjoerprogramma lade foar it bestânsysteem wêr't jo /boot hawwe en de kernel direkt fanôf lade mei UEFI. De bestjoerder moat fansels yn 'e ESP-partysje pleatst wurde. Dit is sawat wat bootloaders lykas GRUB dogge. Mar it hichtepunt is dat alle faak brûkte GRUB-funksjes al yn UEFI binne. Mear krekt yn syn downloadbehearder. En om noch saai te wêzen, hat de UEFI-bootmanager yn guon saken noch mear mooglikheden.
It liket in prachtige oplossing te wêzen, mar d'r is ien "MAR" (of leaver, it wie, mar dêroer letter mear). It feit is dat it UEFI-bestjoerdersysteem frij simpel is. D'r is net sa'n ding as it montearjen fan in bestânsysteem of it assosjearjen fan in bestjoerder mei in spesifyk apparaat. D'r is in systeemoprop mei de konvinsjonele namme Map, dy't elke bestjoerder op syn beurt nimt en besiket it te assosjearjen mei alle, op syn minst passende apparaten. En as de bestjoerder it apparaat koe ophelje, dan wurdt in mapping makke - in ferbiningsrekord. Dit is krekt hoe't de nij laden bestjoerder inisjalisearre wurde moat yn in mienskiplike heap mei alle oaren. En alles wat jo nedich binne is ien bit (LOAD_OPTION_FORCE_RECONNECT) yn te stellen op 1 yn 'e bootrecord fan' e bestjoerder en UEFI sil dizze globale remap dwaan nei it laden.
Mar dit is net sa maklik te dwaan. It standert efibootmgr-hulpprogramma (dat wurdt brûkt om de UEFI-offloadbehearder te konfigurearjen) wit net hoe (of leaver, wist net hoe) dit bit yn te stellen. Ik moast it mei de hân ynstallearje fia in nochal yngewikkelde en gefaarlike proseduere.
En nochris, nei't ik besocht it mei myn hannen te dwaan, koe ik it net stean en formalisearre ûntwikkelders freegje om dizze funksje ta te foegjen.
Ferskate dagen ferrûn, mar gjinien joech oandacht oan myn fersyk. En út nijsgjirrigens seach ik nei de boarnekoade ... ik forkearde it, en fûn út op myn knibbels hoe't ik dizze funksje taheakje soe ... "Op myn knibbels" om't ik soks net ynstallearre en de boarne bewurke koade direkt yn 'e browser.
Ik ken C (de programmeartaal) tige oerflakkich, mar ik sketste in ûngefear oplossing (meast copy-paste)... en doe tocht ik - teminsten haw ik dêr wierskynlik in protte flaters (myn eardere besykjen om in oar syn te bewurkjen C-koade waarden foltôge oer de 10e kear) Ik sil in Pull Request útjaan. Goed .
En dêr die bliken dat Travis CI hechte wie om pull-oanfragen te kontrolearjen. En hy fertelde my iverich al myn flaters. No, as d'r bekende flaters binne, is it net nedich om it te reparearjen: wer, direkt yn 'e browser, en op' e fjirde poging wurke de koade (in prestaasje foar my).
En krekt sa, sûnder de browser te ferlitten, haw ik in heul echte Pull Request opmakke yn in hulpprogramma dat wurdt brûkt yn hast alle moderne Linux-distribúsjes.
Ik wie ferrast troch it feit dat, sûnder de taal echt te witten, sûnder wat yn te stellen (ôfhinklikens fereaskje nochal wat bibleteken foar gearstalling), en sûnder ea de kompilator út te fieren, ik gewoan in folslein wurkjende en brûkbere funksje yn 'e browser .
Myn fersyk bleau lykwols sûnt 19 maart 2019 net reageare, en ik wie it al begon te ferjitten.
Mar juster is dit fersyk tafoege oan master.
Dus wêr giet myn ferhaal oer? En hy praat oer it feit dat, yn it ramt fan moderne technologyen, it die bliken dat echte koade al yn 'e browser skreaun wurde kin, sûnder lokale ûntwikkelingsynstruminten en ôfhinklikens yn te setten.
Boppedat, ik moat tajaan, dit is al myn twadde pull-oanfraach foar bekende (op syn minst yn smelle rûnten) nutsbedriuwen. De lêste kear resultearre myn fersyk om de werjefte fan guon fjilden yn 'e SyncThing-webynterface te korrigearjen yn myn letterlik ien-line bewurking yn in omjouwing dy't ik hielendal net ken.
Allinnich registrearre brûkers kinne meidwaan oan 'e enkête. , asjebleaft.
Moat ik mear skriuwe of net?
-
ja
-
net wurdich
294 brûkers stimden. 138 brûkers ûntholden har.
Boarne: www.habr.com