Jeg vil fortælle om en sjov situation, der skete for mig, og hvordan man bliver bidragsyder til et kendt projekt.
For ikke så længe siden arbejdede jeg på en idé: opstart af Linux direkte fra UEFI…
Idéen er ikke ny, og der er en del vejledninger om emnet. En af dem kan ses
Mine langvarige forsøg på at løse dette problem har udmøntet sig i en ret veludformet . Løsningen er fuldt ud funktionel, og jeg bruger den på nogle af mine hjemmecomputere. En smule mere detaljeret er denne løsning beskrevet .
Essensen af UEFI-Boot er, at ESP (EFI-systempartitionen) fusioneres med katalogen /boot. Det vil sige, at alle kerner og initrd-billeder placeres på den samme partition, som UEFI kan starte eksekverbare filer fra, og specifikt starte systembootloaderne. Men selve Linux-kernen samles allerede i mange distributioner med indstillingen UEFISTUB, som giver kernen mulighed for at starte fra UEFI.
Der er en ubehagelig detalje ved denne løsning — ESP-partitionen er formateret i FAT32, hvor det ikke er muligt at oprette hårde links (som systemet regelmæssigt opretter ved opdatering af initrd). Og der er ikke noget kriminelt i det, men det er ikke særlig behageligt at se systemadvarsler ved opdatering af kernen komponenter…
Der er også en anden vej.
UEFI bootloaderen (den, hvor OS bootloaderen skal skrives) kan, udover Linux bootloadere/kerner, også indlæse drivere. Så man kan indlæse driveren til det filsystem, hvor dit /boot ligger, og direkte derfra indlæse kernen via UEFI. Driveren skal naturligvis placeres i ESP-partitionen. Det er præcis, hvad bootloadere som GRUB beskæftiger sig med. Men det interessante er, at mange af de ofte anvendte funktioner fra GRUB allerede findes i UEFI. Mere præcist i dens boot manager. Og hvis man skal være lidt mere nørdet, så har UEFI boot manageren endda flere muligheder i nogle henseender.
Det ser ud til at være en flot løsning, men der er et "MEN" (egentlig var der, men mere om det senere). Det er sådan set, at UEFI-driverens system er ret ligetil. Der findes ikke noget som montering af filsystemet eller binding af driveren til et specifikt device. Der er et systemopkald med det betingede navn Map, som tager hver driver i tur og orden og forsøger at forbinde den med alle, der nogenlunde passer til enhederne. Og hvis driveren kan tilslutte en enhed, skabes der en mapping - en bindingspost. Det er sådan, at alle de andre også skal initialiseres sammen med den nyindlæste driver. Og det, der bare skal gøres, er at sætte en bit i opstartsposten for driveren (LOAD_OPTION_FORCE_RECONNECT) til 1, og UEFI vil derefter foretage denne globale remap efter indlæsningen.
Men at gøre dette er ikke så let. Den standardværktøj efibootmgr (som bruges til at konfigurere UEFI-load manageren) kunne ikke (eller rettere sagt, kunne ikke tidligere) sætte denne bit. Man måtte sætte den manuelt gennem en ret kompleks og farlig procedure.
Og endnu en gang, da jeg forsøgte at gøre dette manuelt, kunne jeg ikke holde det ud og oprettede med en anmodning til udviklerne om at tilføje denne mulighed.
Der gik et par dage, men ingen reagerede på min anmodning. Og af nysgerrighed kiggede jeg på kildekoden… jeg forgreb mig på den, og klurede så, hvordan denne funktion kunne tilføjes… jeg gjorde det fra bunden fordi jeg ikke havde installeret noget, og redigerede kildekoden direkte i browseren.
C (programmeringssprog) kender jeg kun overfladisk, men jeg skitserede dog en løsning (primært ved at kopiere og indsætte)… og så kom jeg til at tænke — men selvom jeg sikkert har en masse fejl (mine tidligere forsøg på at rette andres C-kode blev kun samlet ved tiende forsøg) ville jeg oprette en Pull Request. Og så .
Der viste sig at være tilsluttet Travis CI til kontrol af pull requests. Og det gav mig omhyggeligt alle mine fejl. Nå, så hvis fejlene er kendte — hvorfor ikke rette dem: igen direkte i browseren, og på fjerde forsøg blev koden samlet (en bedrift for mig).
Og sådan, uden at forlade browseren, oprettede jeg en helt reel Pull Request til værktøjet, som bruges i næsten alle moderne Linux-distributioner.
Jeg blev selv overrasket over, at jeg, uden at kende sproget ordentligt og uden at have konfigureret noget (der er en hel bunke biblioteker nødvendig for opsætningen), og uden nogensinde at have startet kompilatoren, bare i browseren "kodede" en helt funktionel og nyttig feature.
Men min forespørgsel hængte uden reaktion siden 19. marts 2019, og jeg begyndte allerede at glemme den.
Men i går blev denne forespørgsel tilføjet til master.
Så hvad handler min historie om? Den handler om, at med moderne teknologier viser det sig, at man allerede kan skrive rigtig kode i browseren uden at implementere lokale udviklingsværktøjer og afhængigheder.
Desuden må jeg indrømme, at det allerede er min anden pull-request til kendte (i det mindste i snævre kredse) værktøjer. Sidste gang førte min anmodning om at ændre visningen af nogle felter i webgrænsefladen til SyncThing til en bogstavelig en-linjers rettelse i et miljø, jeg slet ikke kendte.
Kun registrerede brugere kan deltage i undersøgelsen. , please.
Skal jeg skrive mere eller ej?
ja
hvis dine strenge er lange nok (fra 100-200 tegn). I så fald bør du overveje at anvende komprimeringsalgoritmer som deflate.
294 brugere stemte. 138 brugere abstene.
Kilde: habr.com
