Je vais vous parler de la curieuse situation qui m'est arrivée et comment devenir contributeur à un projet célèbre.
Il n'y a pas si longtemps, j'étais occupé avec une idée: démarrer Linux directement depuis UEFI ...
L'idée n'est pas nouvelle et il existe un certain nombre de manuels sur ce sujet. L'un d'eux peut être vu
ici.En fait, mes tentatives de longue date pour résoudre ce problème ont abouti à une
solution bien formée. La solution fonctionne assez bien et je l'utilise sur des parties de mes machines à domicile. Cette solution est décrite plus en détail
ici .
L'essence de UEFI-Boot est que la partition ESP (EFI System Partition) est combinée avec le répertoire / boot. C'est-à-dire tous les noyaux et les images de démarrage (initrd) sont situés dans la même section à partir de laquelle UEFI peut exécuter des fichiers exécutables et, en particulier, exécuter des chargeurs de démarrage système. Mais le noyau Linux lui-même est déjà intégré dans de nombreuses distributions avec l'option UEFISTUB, qui permet de lancer le noyau depuis UEFI.
Cette solution a un moment désagréable - 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 d'initrd). Et il n'y a rien de particulièrement criminel à ce sujet, mais ce n'est pas très agréable de voir les avertissements du système lors de la mise à jour des composants du noyau ...
Il y a une autre façon.
Le gestionnaire de démarrage UEFI (celui où vous devez enregistrer le chargeur de système d'exploitation) peut charger des pilotes en plus des chargeurs / noyaux Linux. Vous pouvez donc charger le pilote du système de fichiers où vous avez / boot et directement à partir de là charger le noyau en utilisant UEFI. Le pilote, bien sûr, doit être placé dans la section ESP. C'est ce que font les chargeurs GRUB. Mais le fait saillant est que toutes les fonctions GRUB fréquemment utilisées sont déjà dans UEFI. Plus précisément dans son gestionnaire de téléchargement. Et pour être encore plus ennuyeux, le gestionnaire de démarrage UEFI a encore plus d'options dans certains domaines.
Cela semble être une belle solution, mais il y en a un «MAIS» (ou plutôt il l'était, mais plus à ce sujet plus tard). Le fait est que le système de pilote UEFI est assez simple. Il n’existe pas de montage de système de fichiers ou d’association d’un pilote à un périphérique spécifique. Il existe un appel système avec le nom conditionnel Map (Eng.) Qui prend chaque pilote à tour de rôle et essaie de le connecter à tous, au moins aux périphériques appropriés. Et si l'appareil peut prendre le pilote, le mappage est créé - un enregistrement de liaison. C'est exactement ainsi que le pilote nouvellement chargé doit être initialisé dans le tas commun avec tous les autres. Et tout ce qui est nécessaire est de mettre un bit (LOAD_OPTION_FORCE_RECONNECT) en 1 dans l'enregistrement de démarrage du pilote et UEFI fera ce même remappage global après le chargement.
Mais ce n'est pas si facile à faire. L'utilitaire efibootmgr standard (au moyen duquel le gestionnaire de déchargement UEFI est configuré) ne sait pas (ou plutôt ne savait pas) comment définir ce bit. J'ai dû le mettre avec mes mains à travers une procédure assez compliquée et dangereuse.
Et encore une fois, après avoir essayé de le faire avec mes mains, je n'ai pas pu le supporter et j'ai publié un
problème sur GitHub demandant aux développeurs d'ajouter cette fonctionnalité.
Plusieurs jours se sont écoulés, mais personne n'a prêté attention à ma demande. Et par curiosité, j'ai regardé la source ... fourchue, et j'ai pensé "à genoux" comment ajouter cette fonctionnalité ... "A genoux" parce que je n'ai rien réglé de tel et j'ai édité la source directement dans le navigateur.
C (langage de programmation) Je sais très superficiellement, mais j'ai jeté une solution (principalement du copier-coller) ... enfin, j'ai pensé - mais au moins j'ai probablement beaucoup d'erreurs là-bas (mes tentatives précédentes pour éditer le code C de quelqu'un d'autre ont été collectées à partir du 10) Je vais émettre une demande Pull. Bien
conçu .
Et là, Travis CI a été vissé pour vérifier les demandes de tirage. Et il m'a soigneusement donné toutes mes erreurs. Eh bien, si des erreurs sont connues - tout ce qui serait corrigé: encore une fois directement dans le navigateur, et dès la quatrième tentative, le code a été collecté (une réussite pour moi).
Et donc, sans sortir du navigateur, j'ai conçu une demande de tirage très réelle dans un utilitaire utilisé dans presque toutes les distributions Linux modernes.
J'ai été surpris par le fait que, sans vraiment connaître la langue et sans rien configurer moi-même (selon les dépendances, j'ai besoin d'un petit paquet de bibliothèques pour l'assemblage) et même sans même démarrer le compilateur, je viens de «faire apparaître» une fonctionnalité fonctionnelle et utile dans le navigateur .
Cependant, ma demande est suspendue sans réaction depuis le 19 mars 2019 et j'ai déjà commencé à l'oublier.
Mais hier, cette demande a été ajoutée au master.
Alors, quelle est mon histoire. Et il s'agit du fait que, dans le cadre des technologies modernes, il s'est avéré que le vrai code peut déjà être écrit dans un navigateur sans avoir à déployer localement des outils de développement et des dépendances.
De plus, je dois admettre que c'est ma deuxième demande de tirage vers des utilitaires bien connus (au moins dans les cercles étroits). La dernière fois, ma demande de corriger l'affichage de certains champs dans l'interface Web SyncThing a entraîné ma modification littéralement sur une ligne dans un environnement que je ne connais pas du tout.