Framtiden är redan här eller koda direkt i webbläsaren

Jag ska berätta om en komisk situation som hände mig och hur man blir en bidragsgivare till ett välkänt projekt.

Nyligen arbetade jag med en idé: att ladda Linux direkt från UEFI…
Idén är inte ny och det finns ett antal manualer på detta ämne. En av dem kan man titta på ). Ett typiskt exempel på användning:

Mina långvariga försök att lösa denna fråga har leder till ett ganska väl utformat beslutet. Lösningen fungerar bra och jag använder den på några av mina hemmamaskiner. En mer detaljerad beskrivning av denna lösning finns i ). Ett typiskt exempel på användning:.

Kärnan i UEFI-boot är att ESP (EFI System Partition) partitionen kombineras med katalogen /boot. Det vill säga att alla kärnor och initiala laddningsbilder (initrd) placeras på just den partition från vilken UEFI kan köra körbara filer och specifikt startladdare för systemet. Men själva Linux-kärnan kompilieras redan i många distributioner med alternativet UEFISTUB, vilket gör att själva kärnan kan starta från UEFI.

Det finns en obehaglig aspekt av denna lösning — ESP-partitionen är formaterad i FAT32, där det inte går att skapa hårda länkar (som systemet regelbundet skapar vid uppdatering av initrd). Och det finns inget särskilt brottsligt med detta, men det är inte så trevligt att se systemvarningar vid uppdatering av kärnkomponenter…

Det finns en annan väg.

UEFI-laddaren (den som man måste ange operativsystemets laddare till) kan förutom att ladda laddare/kärnor för Linux även ladda drivrutiner. Så man kan ladda drivrutinen för det filsystem där man har sin /boot och direkt från det ladda kärnan med hjälp av UEFI. Drivrutinen måste naturligtvis placeras i ESP-partitionen. Ungefär detta gör laddare som GRUB. Men poängen är just att alla ofta använda funktioner i GRUB redan finns i UEFI. Närmare bestämt i dess laddarhanterare. Och om man ska vara ännu mer petig, så har UEFI-laddarhanteraren faktiskt fler möjligheter i vissa avseenden.

Det verkar vara en vacker lösning, men det finns ett "MEN" (eller snarare fanns det, men mer om det senare). Det handlar om att UEFI-drivrutinsystemet är ganska enkelt utformat. Det finns inget sådant koncept som montering av filsystem eller koppling av en drivrutin till en specifik enhet. Det finns ett systemanrop med det villkorliga namnet Map som går igenom varje drivrutin och försöker koppla den till alla, mer eller mindre lämpliga enheter. Om drivrutinen lyckas koppla till en enhet, skapas en mappning — en kopplingspost. Just så måste den nyinlästa drivrutinen initieras tillsammans med alla andra. Och allt som behövs är att sätta en bit (LOAD_OPTION_FORCE_RECONNECT) i 1 i drivrutinens startpost, så kommer UEFI efter att ha laddat den att göra den globala remappen.

Men att göra detta är inte så enkelt. Den standardmässiga verktygen efibootmgr (som används för att konfigurera UEFI:s lasthanterare) kan (eller snarare kunde) inte sätta denna bit. Jag var tvungen att göra det manuellt genom en ganska komplex och farlig procedur.

Och så, efter att ha försökt göra detta manuellt igen, kunde jag inte motstå och skapade ett issue på GitHub med en begäran till utvecklarna att lägga till denna funktion.

Det gick några dagar, men ingen uppmärksammade min begäran. Och av nyfikenhet kollade jag på källkoden… forka den och funderade på hur jag skulle kunna lägga till denna funktion "manuellt"… "manuellt" eftersom jag inte installerade något och redigerade direkt i webbläsaren.

Jag känner C (programmeringsspråket) väldigt ytligt, men jag skissade på en lösning (främst genom att kopiera och klistra in)… sen tänkte jag — varför inte skicka en Pull Request, även om jag har säkert mycket fel (mina tidigare försök att rätta andras C-kod gav resultat först efter tio försök). Så jag skapade den.

Och där visade det sig att Travis CI var kopplad för att kontrollera pull requests. Och den gav mig noggrant alla mina fel. Om felen är kända - varför inte rätta dem: återigen direkt i webbläsaren, och efter fjärde försöket så byggdes koden (ett framgång för mig).

Och så, utan att lämna webbläsaren, lämnade jag in en fullt fungerande Pull Request till ett verktyg som används i nästan alla moderna Linux-distributioner.

Jag blev själv förvånad över att jag, utan att riktigt kunna språket och utan att ställa in något (det behövs en hel del beroenden för att bygga), och utan att ens köra kompilatorn, helt enkelt "kodade" en fullt fungerande och användbar funktion direkt i webbläsaren.

Men min begäran hade hängt utan respons sedan den 19 mars 2019, och jag hade nästan glömt bort den.

Men igår lades den här begäran till i master.

Så vad handlar min berättelse om? Den handlar om att inom ramen för moderna teknologier har det visat sig att man faktiskt kan skriva verklig kod i webbläsaren utan att behöva ställa in några lokala utvecklingsverktyg eller beroenden.

Dessutom måste jag erkänna att detta redan är min andra pull request i kända (åtminstone inom smala kretsar) verktyg. Senast resulterade min begäran om att åtgärda visningen av vissa fält i webgränssnittet för SyncThing i en bokstavligen enradig ändring i en miljö som jag överhuvudtaget inte känner till.

Endast registrerade användare kan delta i omröstningen. Logga in, tack.

Ska jag skriva mer eller inte?

• ja

• om

294 användare röstade, 138 användare avstod.

Källa: habr.com