🥇Il futuro è già qui o programmiamo direttamente nel browser

Condividerò un episodio divertente che mi è capitato e come diventare un contributore in un progetto noto.

Non molto tempo fa, ho lavorato su un'idea: caricare Linux direttamente da UEFI…
L'idea non è nuova e ci sono diverse guide su questo tema. Una di esse può essere consultata qui

Le mie lunghe tentativi di risolvere questo problema si sono concretizzati in una soluzione ben definita soluzione. È una soluzione completamente funzionante e la utilizzo su alcune delle mie macchine di casa. Questa soluzione è descritta in modo più dettagliato qui.

Il concetto di UEFI-Boot è che la partizione ESP (EFI System Partition) è combinata con la directory /boot. Cioè, tutti i kernel e le immagini di avvio iniziale (initrd) sono collocati nella stessa partizione da cui l'UEFI può avviare i file eseguibili e, in particolare, avviare i caricamenti del sistema. Ma il kernel Linux stesso è già compilato con l'opzione UEFISTUB in molte distribuzioni, che consente al kernel di essere avviato direttamente dall'UEFI.

C'è un aspetto spiacevole di questa soluzione: la partizione ESP è formattata in FAT32, su cui non è possibile creare collegamenti fisici (che il sistema crea regolarmente durante l'aggiornamento di initrd). Non è niente di grave, ma vedere i messaggi di avviso del sistema durante l'aggiornamento dei componenti del kernel non è molto piacevole...

Esiste anche un altro modo.

Il gestore di avvio UEFI (quello in cui bisogna inserire il bootloader del sistema operativo) è in grado di caricare, oltre ai bootloader/kernel Linux, anche i driver. Quindi, si può caricare il driver di quel filesystem dove si trova /boot e caricare direttamente il kernel tramite UEFI. Ovviamente, il driver deve essere posizionato nella partizione ESP. Questo è più o meno ciò di cui si occupano i bootloader come GRUB. Ma la particolarità è che tutte le funzioni comunemente usate di GRUB sono già disponibili in UEFI. Più precisamente, nel suo gestore di avvio. E per essere ancora più pignoli, il gestore di avvio UEFI ha persino più funzionalità in alcuni aspetti.

Sembra una bella soluzione, ma c'è un "MA" (o meglio, c'era, ma di questo parleremo più tardi). Il fatto è che il sistema dei driver UEFI è piuttosto semplice. Non esiste il concetto di montaggio di un file system o di associazione di un driver a un dispositivo specifico. Esiste una chiamata di sistema con un nome provvisorio Map (in inglese) che prende ogni driver a turno e cerca di associarlo a tutti i dispositivi, anche se non del tutto adatti. Se un driver riesce a collegarsi a un dispositivo, viene creato un mapping — un record di associazione. È così che un driver ricaricato deve inizializzarsi in mezzo agli altri. Ed ecco cosa serve: nell'entry di avvio del driver, bisogna impostare un bit (LOAD_OPTION_FORCE_RECONNECT) a 1 e UEFI, dopo il suo caricamento, farà questo rimappamento globale.

Solo che farlo non è così semplice. L'utility standard efibootmgr (con cui si configura il gestore di avvio UEFI) non è in grado (o meglio, non era in grado) di impostare questo bit. Era necessario impostarlo manualmente tramite una procedura piuttosto complessa e rischiosa.

E così, dopo averci provato un'altra volta manualmente, non ho resistito e ho deciso di procedere. questione su GitHub con la richiesta agli sviluppatori di aggiungere questa funzionalità.

Sono passati alcuni giorni, ma nessuno ha prestato attenzione alla mia richiesta. Per curiosità, ho dato un'occhiata ai sorgenti... ho fatto un fork e ho provato a capire 'a occhio' come aggiungere questa funzione... 'a occhio' perché non ho installato nulla e ho modificato direttamente i sorgenti nel browser.

Il C (linguaggio di programmazione) lo conosco solo superficialmente, ma ho abbozzato una soluzione (principalmente copiando e incollando)... poi ho pensato — visto che sicuramente avrò un sacco di errori (le mie precedenti tentativi di modificare codice C di altri richiedevano almeno dieci prove), farò un Pull Request. E così l'ho fatto.

E lì ho scoperto che era integrato Travis CI per il controllo dei pull request. E mi ha restituito tutte le mie errori con attenzione. Bene, se sono noti gli errori, perché non correggerli: di nuovo direttamente nel browser, e al quarto tentativo il codice si è compilato (un traguardo per me).

E così, senza uscire dal browser, ho creato un Pull Request reale per un'utility che viene utilizzata praticamente in tutte le moderne distribuzioni Linux.

Sono rimasto sorpreso dal fatto che, pur non conoscendo bene la lingua e senza dover configurare nulla (lì ci sono molte dipendenze per la compilazione), e non avendo mai avviato nemmeno il compilatore, ho semplicemente "codificato" una funzionalità utile e operativa direttamente nel browser.

Tuttavia, la mia richiesta è rimasta senza risposta dal 19 marzo 2019, e stavo cominciando a dimenticarla.

Ma proprio ieri questa richiesta è stata aggiunta al master.

Di cosa parla quindi il mio racconto? Riguarda il fatto che, con le moderne tecnologie, è possibile scrivere codice reale direttamente nel browser, senza dover installare alcun strumento di sviluppo o dipendenze localmente.

Va detto che questa è già la mia seconda pull request per utilità conosciute (almeno in certi circoli). L'ultima volta, la mia richiesta di correggere la visualizzazione di alcuni campi nell'interfaccia web di SyncThing si è tradotta in una correzione letteralmente di una sola riga in un ambiente che non conoscevo affatto.

Solo gli utenti registrati possono partecipare al sondaggio. Accedi, per favore.