Je vais vous parler d'une situation curieuse qui m'est arrivée et de la façon de devenir contributeur dans un projet réputé.
Il n'y a pas si longtemps, je me suis occupé d'une idée : le chargement de Linux directement depuis l'UEFI...
L'idée n'est pas nouvelle et il existe un certain nombre de manuels à ce sujet. L'un d'eux peut être consulté
Mes anciennes tentatives pour résoudre cette question se sont transformées en une solution bien formulée . La solution fonctionne tout à fait et je l'utilise sur certaines de mes machines domestiques. Un peu plus de détails sur ce solution sont décrits .
Le principe du démarrage UEFI est que la partition ESP (EFI System Partition) est combinée avec le répertoire /boot. C'est-à-dire que tous les noyaux et les images de démarrage initial (initrd) sont stockés sur cette même partition à partir de laquelle l'UEFI peut exécuter des fichiers exécutables et en particulier démarrer les chargeurs de système. Mais le noyau Linux lui-même est déjà compilé avec l'option UEFISTUB dans de nombreuses distributions, ce qui permet au noyau de démarrer depuis l'UEFI.
Il y a un aspect désagréable à cette solution : la partition ESP est formatée en FAT32, sur laquelle il est impossible de créer des liens durs (que le système crée régulièrement lors de la mise à jour de l'initrd). Et il n'y a rien de particulièrement criminel à cela, mais voir des avertissements du système lors de la mise à jour des composants du noyau n'est pas très agréable...
Il existe également une autre voie.
Le gestionnaire de démarrage UEFI (celui où vous devez inscrire le chargeur du système d'exploitation) sait, en plus des noyaux/chargeurs Linux, charger également des pilotes. Ainsi, vous pouvez charger le pilote du système de fichiers où se trouve votre /boot et directement à partir de là démarrer le noyau avec les moyens de l'UEFI. Évidemment, le pilote doit être placé dans la partition ESP. C'est en gros ce que font les chargeurs comme GRUB. Mais l'astuce est que toutes les fonctions souvent utilisées de GRUB existent déjà dans l'UEFI. Plus précisément, dans son gestionnaire de démarrage. Et pour être un peu plus pointilleux, le gestionnaire de démarrage UEFI a même plus de possibilités sur certaines questions.
Cela semble être une belle solution, mais il y a un "MAIS" (en fait, il y en avait un, mais j'y reviendrai plus tard). En effet, le système de pilotes UEFI est plutôt simple. Il n'y a pas de notion de montage du système de fichiers ou de liaison d'un pilote à un dispositif spécifique. Il y a un appel système avec un nom conditionnel Map qui prend chaque pilote à tour de rôle et essaie de le lier à tous les dispositifs convenables, bon gré mal gré. Si le pilote parvient à connecter le dispositif, une correspondance est créée — un enregistrement de liaison. C'est ainsi que le nouveau pilote doit être initialisé parmi tous les autres. Et il suffit seulement de mettre un bit (LOAD_OPTION_FORCE_RECONNECT) à 1 dans l'enregistrement de démarrage du pilote, et UEFI effectuera cette reconfiguration globale après son chargement.
Le problème, c'est que ce n'est pas si simple à faire. L'outil standard efibootmgr (qui sert à configurer le gestionnaire de démarrage UEFI) ne sait pas (ou plutôt ne savait pas) comment mettre ce bit. Il fallait le faire manuellement via une procédure assez complexe et risquée.
Alors, une fois de plus, en essayant de le faire manuellement, je n'ai pas pu résister et j'ai créé en demandant aux développeurs d'ajouter cette fonctionnalité.
Quelques jours ont passé, mais personne n'a prêté attention à ma demande. Par curiosité, j'ai regardé le code source... j'ai forké, et j'ai essayé de réfléchir "à la main" à comment ajouter cette fonctionnalité... "à la main" parce que je n'ai rien d'autre installé et j'ai édité le code source directement dans le navigateur.
Je connais le C (langage de programmation) très superficiellement, mais j'ai proposé une solution (principalement par copier-coller)... puis j'ai pensé — et même si j'ai sûrement plein d'erreurs (mes précédentes tentatives de corriger du code C d'autres personnes ont abouti après 10 essais), je vais soumettre un Pull Request. Et donc .
Il s'est avéré que Travis CI était intégré pour vérifier les pull requests. Et il m'a soigneusement signalé toutes mes erreurs. Eh bien, si les erreurs sont connues — pourquoi ne pas les corriger : encore une fois dans le navigateur, et avec ma quatrième tentative, le code a été compilé (un accomplissement pour moi).
Et c'est ainsi, sans quitter le navigateur, que j'ai soumis un Pull Request tout à fait concret pour l'outil utilisé pratiquement dans toutes les distributions Linux modernes.
Je suis moi-même surpris par le fait que, ne connaissant pas vraiment la langue et n'ayant rien configuré chez moi (il faut de nombreux paquets de bibliothèques en fonction des dépendances pour la compilation) et n'ayant même jamais lancé le compilateur, j'ai réussi à « coder » une fonctionnalité parfaitement fonctionnelle et utile directement dans le navigateur.
Cependant, ma demande est restée sans réaction depuis le 19 mars 2019, et j'avais commencé à l'oublier.
Mais hier, cette demande a été ajoutée dans master.
Alors, de quoi parle mon récit ? Il s'agit du fait qu'avec les technologies modernes, il est désormais possible d'écrire du code réel dans un navigateur sans déployer localement aucun outil de développement ni dépendances.
D'ailleurs, il faut admettre que c'est déjà ma deuxième demande de tirage dans des utilitaires connus (du moins dans des cercles restreints). La dernière fois, ma demande de corriger l'affichage de certains champs dans l'interface web de SyncThing s'est soldée par une correction littéralement d'une seule ligne dans un environnement que je ne connais même pas.
Seuls les utilisateurs enregistrés peuvent participer au sondage. , s'il vous plaît.
Faut-il écrire encore ou pas ?
oui
peut-être
294 utilisateurs ont voté. 138 utilisateurs se sont abstenus.
Source : habr.com
