E ardhmja është këtu ose kodojmë direkt në shfletues

Do të flas për një situatë interesante që më ndodhi dhe se si të bëhesh kontribuues në një projekt të njohur.

Nuk është hera e parë që merrem me një ide: ngarkimi i Linux-it direkt nga UEFI

Ideja nuk është e re dhe ekziston një numër manualesh mbi këtë temë. Një nga ato mund të shihet këtu

Prandaj, përpjekjet e mia të gjata për të zgjidhur këtë çështje rezultuan në një zgjidhje të shkruar mirë zgjidhje. Zgjidhja është plotësisht funksionale dhe unë e përdor atë në disa nga kompjuterët e mi të shtëpisë. Pak më hollësisht, kjo zgjidhje përshkruhet këtu.

Thelbi i UEFI-Boot është se ESP (EFI System Partition) përputhet me katalogun /boot. Pra, të gjitha bërthamat dhe imazhet e nisjes (initrd) vendosen në atë ndarje nga e cila UEFI mund të nisë skedarët ekzekutivë dhe në veçanti të nisë ngarkuesit e sistemit. Por bërthama e Linux-it tashmë në shumë distribuime ndërtohet me opsionin UEFISTUB, i cili lejon bërthamën të nisë nga UEFI.

Kyky i kĂ«tij zgjidhjeje ka njĂ« problem tĂ« pakĂ«ndshĂ«m — ESP Ă«shtĂ« formatuar nĂ« FAT32, mbi tĂ« cilin nuk Ă«shtĂ« e mundur tĂ« krijosh lidhje tĂ« forta (tĂ« cilat sistemi i krijon rregullisht gjatĂ« pĂ«rditĂ«simit tĂ« initrd). Dhe nuk ka asgjĂ« tĂ« veçantĂ« nĂ« kĂ«tĂ«, por tĂ« shohĂ«sh paralajmĂ«rimet e sistemit gjatĂ« pĂ«rditĂ«simit tĂ« komponentĂ«ve tĂ« kernel-it — nuk Ă«shtĂ« shumĂ« e kĂ«ndshme...

Ka dhe një rrugë tjetër.

Menaxheri i ngarkesës UEFI (atë që duhet të shkruash për ngarkuesin e OS) mund të ngarkojë përveç ngarkuesve/kernel-eve Linux edhe drver të tjerë. Kështu që mund të ngarkosh drverin e asaj sistemi skedarësh, ku e ke /boot dhe përmes UEFI të ngarkosh direkt kernel-in. Drveri, natyrisht, duhet të vendoset në ndarjen ESP. Kështu në të vërtetë merret me këtë ngarkuesit si GRUB. Por gjëja interesante është se të gjitha funksionet e përdorura shpesh të GRUB janë tashmë të pranishme në UEFI. Më saktë, në menaxherin e tij të ngarkesës. Dhe nëse dëshiron të jesh edhe më i saktë, menaxheri i ngarkesës UEFI ka madje më shumë mundësi në disa çështje.

Duket si njĂ« zgjidhje e bukur, por ka njĂ« "POR" (mĂ« saktĂ«sisht kishte, por pĂ«r kĂ«tĂ« mĂ« vonĂ«). E vĂ«rteta Ă«shtĂ« se sistemi i drejtorĂ«ve UEFI Ă«shtĂ« mjaft i thjeshtĂ«. Nuk ka njĂ« koncept si montimi i sistemit tĂ« files apo lidhja e drejtuesit me njĂ« pajisje tĂ« veçantĂ«. Ka njĂ« thirrje sistemore me njĂ« emĂ«r tĂ« kushtuar Map (angl.), i cili merr secilin drejtor njĂ« nga njĂ« dhe pĂ«rpiqet ta lidhĂ« atĂ« me tĂ« gjitha pajisjet qĂ« pĂ«rshtaten, mĂ« mirĂ« ose mĂ« keq. Dhe nĂ«se drejtori arriti tĂ« lidhet me pajisjen, krijohet njĂ« mapim — njĂ« regjistĂ«r lidhĂ«s. KĂ«shtu, drejtori i ri duhet tĂ« inicializohet nĂ« kĂ«tĂ« grumbull me tĂ« gjithĂ« tĂ« tjerĂ«t. Dhe vetĂ«m kaq mjafton — nĂ« regjistrimin e ngarkesĂ«s sĂ« drejtuesit duhet tĂ« vendoset njĂ« bit (LOAD_OPTION_FORCE_RECONNECT) nĂ« 1 dhe UEFI pas ngarkimit tĂ« tij do tĂ« bĂ«jĂ« kĂ«tĂ« rimapim global.

Por, ta bësh këtë nuk është aq e lehtë. Utilitari standard efibootmgr (me të cilin realizohet konfigurimi i menaxherit të ngarkesës UEFI) nuk di (më saktësisht, nuk dinte) të vendosë këtë bit. Duhej ta vendosja manualisht përmes një procedure mjaft të ndërlikuar dhe të rrezikshme.

Dhe kështu, për herë të fundit duke provuar ta bëj këtë manualisht, nuk e përballova dot dhe e organizova çështja në GitHub me një kërkesë për zhvilluesit për të shtuar këtë mundësi.

Kanë kaluar disa ditë, por askush nuk i ka kushtuar vëmendje kërkesës sime. Dhe nga kurioziteti, shikova burimet... e fork-ut, dhe mendoja se si mund ta shtoja këtë funksionalitet... "Në mënyrë rudimentare" sepse nuk kam instaluar diçka të tillë dhe redaktoja burimet direkt në shfletues.

C (gjuha e programimit) e njoh shumĂ« pak, por pĂ«rfunda njĂ« zgjidhje tĂ« pĂ«rafĂ«rt (shumica kopjimi-ngjitje)... pastaj mĂ« erdhi nĂ« mendje — ndonjĂ«herĂ« kam sigurisht njĂ« mori gabimesh (pĂ«rpjekjet e mia tĂ« kaluara pĂ«r tĂ« rregulluar kodin e huaj C ishin e paktĂ«n tĂ« dhjetĂ«ta) do ta organizoj njĂ« Pull Request. NdĂ«rsa e organizova.

Dhe aty u zbulua se kishte njĂ« Travis CI tĂ« lidhur pĂ«r tĂ« kontrolluar pull requestet. Dhe ai me jepte kĂ«mbĂ«ngulĂ«sisht tĂ« gjitha gabimet e mia. Po nĂ«se gabimet janĂ« tĂ« njohura — pĂ«rse tĂ« mos i rregulloj: pĂ«rsĂ«ri direkt nĂ« shfletues, dhe nĂ« pĂ«rpjekjen e katĂ«rt kodi u ndĂ«rtua (njĂ« arritje pĂ«r mua).

Dhe kështu, pa dalë nga shfletuesi, organizova një Pull Request mjaft të vërtetë në utilitarin që përdoret pothuajse në të gjitha shpërndarjet moderne të Linux.

Më befasoi vetë fakti që unë, duke mos e ditur gjuhën mirë, dhe pa bërë asgjë në konfigurim (aty janë të nevojshme një sërë bibliotekash për ndërtimin) dhe pa e hapur kurrë ndihmën e zhvilluesit, thjesht në shfletues "programova" një mundësi tërheqëse e funksionale.

Megjithatë, kërkesa ime mbeti pa përgjigje që nga 19 marsi 2019, dhe unë tashmë po filloja ta harroja atë.

Por dje, kjo kërkesë u shtua në master.

ÇfarĂ« Ă«shtĂ« tregimi im? Ai Ă«shtĂ« pĂ«r atĂ« se me teknologjitĂ« moderne rezulton se kodi real mund tĂ« shkruhet tashmĂ« nĂ« shfletues, pa ndihmĂ«n e asnjĂ« instrumenti zhvillimi dhe varĂ«sish.

Duhet të pranoj se ky është pallati im i dytë i kërkesave në utilitarët e njohur (të paktën në rrethet e ngushta). Herën e kaluar, kërkesa ime për të korrigjuar shfaqjen e disa fushave në ndërfaqen web të SyncThing rezultoi në një korrigjim të vetëm rresht në një mjedis që unë nuk e dija fare.

Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. Hyni, ju lutemi.

Duhet të shkruaj më tej apo jo?

  • po

  • nuk duhet

294 përdorues votuan. 138 përdorues abstenuan.

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster