Vou contar sobre uma situação curiosa que aconteceu comigo e sobre como se tornar um contribuinte em um projeto conhecido.
Não faz muito tempo que estive envolvido com uma ideia: carregar o Linux diretamente do UEFI...
A ideia não é nova e há uma quantidade considerável de manuais sobre esse tema. Um deles pode ser consultado
Na verdade, minhas antigas tentativas de resolver essa questão resultaram em um projeto bem estruturado . A solução é totalmente funcional e eu a utilizo em parte das minhas máquinas domésticas. Um pouco mais detalhadamente, essa solução está descrita .
A essência do UEFI-Boot é que a ESP (Partição de Sistema EFI) se combina com o diretório /boot. Ou seja, todos os núcleos e as imagens de inicialização (initrd) são colocados na mesma partição a partir da qual o UEFI pode executar arquivos executáveis e, em particular, iniciar gerenciadores de inicialização do sistema. Porém, o próprio núcleo do Linux já é compilado com a opção UEFISTUB em muitas distribuições, o que permite que o próprio núcleo inicie a partir do UEFI.
Há um inconveniente nessa solução — a partição ESP é formatada em FAT32, onde não é possível criar links duros (que o sistema cria regularmente ao atualizar o initrd). E não há nada de particularmente criminoso nisso, mas receber avisos do sistema durante a atualização dos componentes do núcleo não é muito agradável...
Há outro caminho.
O gerenciador de inicialização UEFI (aquele onde é necessário adicionar o carregador do sistema operacional) consegue, além de carregadores/núcleos Linux, carregar também drivers. Portanto, você pode carregar o driver do sistema de arquivos onde está seu /boot e carregar o núcleo diretamente a partir daí usando o UEFI. O driver, naturalmente, deve ser colocado na partição ESP. Isso é aproximadamente o que fazem gerenciadores como o GRUB. Mas a sacada é que todas as funções frequentemente usadas do GRUB já estão no UEFI. Ou melhor, em seu gerenciador de inicialização. E se quisermos ser mais detalhistas, o gerenciador de inicialização UEFI tem até mais recursos em certas questões.
Parece ser uma solução bonita, mas há um "MAS" (ou melhor, havia, mas falarei sobre isso depois). O fato é que o sistema de drivers UEFI é relativamente simples. Não existe um conceito de montagem de sistema de arquivos ou de vinculação de driver a um dispositivo específico. Há uma chamada de sistema com um nome condicional Map (em inglês) que pega cada driver em ordem e tenta vinculá-lo a todos os dispositivos que, de alguma forma, se encaixam. E se o driver conseguir se conectar ao dispositivo, então é criado um mapeamento — uma entrada de ligação. Assim, na confusão com todos os outros, o novo driver deve ser inicializado. E tudo o que é necessário — na entrada de inicialização do driver, configurar um bit (LOAD_OPTION_FORCE_RECONNECT) como 1 e o UEFI fará esse remapeamento global após o carregamento.
Só que fazer isso não é tão simples. A ferramenta padrão efibootmgr (com a qual se configura o gerenciador de inicialização UEFI) não sabe (ou melhor, não sabia) como configurar esse bit. Era necessário configurá-lo manualmente através de um procedimento bastante complexo e perigoso.
E mais uma vez, ao tentar fazer isso manualmente, não aguentei e criei pedindo aos desenvolvedores que adicionassem essa funcionalidade.
Se passaram alguns dias, mas ninguém prestou atenção ao meu pedido. E, por curiosidade, fui dar uma olhada no código-fonte... forklei, e pensei em como adicionar esse recurso "na unha"... "Na unha" porque não utilizei nada específico e editei o código-fonte direto no navegador.
Eu conheço C (a linguagem de programação) de maneira muito superficial, mas rascunhei uma solução (principalmente copiando e colando)... e então pensei — e mesmo que haja uma porção de erros (minhas tentativas anteriores de corrigir o código C de outra pessoa só compilavam na décima tentativa) vou criar um Pull Request. E assim, .
E ao fazer isso, descobri que havia um Travis CI implementado para verificar os pull requests. E ele me informou todos os meus erros. Bem, se os erros são conhecidos — por que não corrigir: novamente direto no navegador, e na quarta tentativa o código foi compilado (um feito para mim).
E assim, sem sair do navegador, criei um Pull Request totalmente real para uma ferramenta que é usada praticamente em todas as distribuições modernas do Linux.
Fiquei surpreso ao perceber que, sem conhecer a língua e sem configurar nada (são necessárias várias bibliotecas para a compilação), e sem nunca ter executado o compilador, consegui "programar" uma funcionalidade útil e funcional diretamente no navegador.
No entanto, meu pedido ficou sem resposta desde 19 de março de 2019, e eu já havia começado a esquecê-lo.
Mas ontem, esse pedido foi adicionado ao master.
Sobre o que trata minha história? Trata-se do fato de que, com as tecnologias atuais, já é possível escrever código real no navegador, sem precisar instalar ferramentas de desenvolvimento e dependências localmente.
Vale a pena mencionar que este é meu segundo pull request em utilitários conhecidos (pelo menos em círculos restritos). Da última vez, meu pedido para corrigir a exibição de alguns campos na interface web do SyncThing resultou em uma correção de apenas uma linha em um ambiente que eu não conhecia.
Apenas usuários registrados podem participar da pesquisa. , por favor.
Devo continuar escrevendo ou não?
sim
não é recomendado
Votaram 294 usuários. 138 usuários se abstiveram.
Fonte: habr.com
