Vou falar sobre a curiosa situação que aconteceu comigo e como me tornar um colaborador de um projeto famoso.
Há pouco tempo, eu estava ocupado com uma idéia: inicializar o Linux diretamente da UEFI ...
A ideia não é nova e há vários manuais sobre esse assunto. Um deles pode ser visto
aqui.Na verdade, minhas tentativas de longa data de resolver esse problema resultaram em uma
solução bem formada. A solução está funcionando e eu a uso em partes de minhas máquinas domésticas. Esta solução é descrita em mais detalhes
aqui .
A essência do UEFI-Boot é que a partição ESP (EFI System Partition) é combinada com o diretório / boot. I.e. todos os kernels e imagens de inicialização (initrd) estão localizados na mesma seção a partir da qual o UEFI pode executar arquivos executáveis e, em particular, executar carregadores de inicialização do sistema. Mas o próprio kernel do Linux já está incorporado em muitas distribuições com a opção UEFISTUB, que permite que o kernel seja iniciado a partir da UEFI.
Essa solução tem um momento desagradável - a partição ESP é formatada em FAT32, na qual é impossível criar links físicos (que o sistema cria regularmente ao atualizar o initrd). E não há nada de particularmente criminoso nisso, mas não é muito agradável ver avisos do sistema ao atualizar os componentes do kernel ...
Existe outro caminho.
O gerenciador de inicialização UEFI (aquele em que você precisa registrar o carregador do SO) pode carregar drivers além dos carregadores / kernels do Linux. Portanto, você pode carregar o driver do sistema de arquivos no qual você tem / boot e diretamente a partir daí carregar o kernel usando UEFI. O motorista, é claro, precisa ser colocado na seção ESP. É isso que os carregadores GRUB fazem. Mas o destaque é que todas as funções GRUB usadas com frequência já estão no UEFI. Mais precisamente em seu gerenciador de downloads. E para ser ainda mais chato, o gerenciador de inicialização UEFI tem ainda mais opções em algumas áreas.
Parece ser uma solução bonita, mas existe uma "MAS" (ou melhor, era, mas mais sobre isso mais tarde). O fato é que o sistema de driver UEFI é bastante direto. Não existe algo como montar um sistema de arquivos ou associar um driver a um dispositivo específico. Há uma chamada do sistema com o nome condicional Mapa (Port.), Que leva cada driver por vez e tenta conectá-lo a todos, pelo menos aos dispositivos adequados. E se o dispositivo puder pegar o driver, o mapeamento será criado - um registro obrigatório. É exatamente assim que o driver recém-carregado deve ser inicializado no heap comum com todos os outros. E tudo o que é necessário é colocar um bit (LOAD_OPTION_FORCE_RECONNECT) em 1 no registro de inicialização do driver e a UEFI fará o mesmo remapeamento global após carregá-lo.
Mas isso não é tão fácil de fazer. O utilitário padrão efibootmgr (por meio do qual o gerenciador de descarregamento UEFI está configurado) não sabe como (ou melhor, não sabia como) definir esse bit. Eu tive que colocá-lo com as mãos em um procedimento bastante complicado e perigoso.
E mais uma vez, tendo tentado fazer isso com minhas mãos, eu não aguentei e escrevi um
problema no GitHub pedindo aos desenvolvedores que adicionassem esse recurso.
Vários dias se passaram, mas ninguém prestou atenção ao meu pedido. Por curiosidade, olhei a fonte ... bifurquei-me e imaginei "de joelhos" como adicionar esse recurso ... "de joelhos" porque não defini nada assim e editei a fonte diretamente no navegador.
C (linguagem de programação) eu sei muito superficialmente, mas lancei uma solução (principalmente copiar e colar) ... bem, então pensei - e pelo menos provavelmente tenho muitos erros por lá (minhas tentativas anteriores de editar o código C de outra pessoa foram coletadas a partir do dia 10) Vou emitir uma solicitação de recebimento. Bem
desenhado .
E lá Travis CI foi ferrado para verificar solicitações de recebimento. E ele cuidadosamente me deu todos os meus erros. Bem, se erros forem conhecidos - o que quer que seja corrigido: novamente no navegador e, na quarta tentativa, o código foi coletado (uma conquista para mim).
E assim, sem sair do navegador, projetei uma solicitação de solicitação muito real em um utilitário usado em quase todas as distribuições modernas do Linux.
Fiquei surpreso com o fato de eu, sem realmente conhecer o idioma, e não ter configurado nada (dependendo das dependências, preciso de um pequeno pacote de bibliotecas para montagem) e, mesmo sem iniciar o compilador, apenas “abri” um recurso útil e útil no navegador .
No entanto, meu pedido foi suspenso sem reação desde 19 de março de 2019 e eu já comecei a esquecê-lo.
Mas ontem, essa solicitação foi adicionada ao mestre.
Então, qual é a minha história. E é sobre o fato de que, dentro da estrutura das tecnologias modernas, ocorreu que o código real já pode ser gravado em um navegador sem a necessidade de implantar ferramentas e dependências de desenvolvimento localmente.
Além disso, devo admitir, esta é minha segunda solicitação de recebimento de utilidades conhecidas (pelo menos em círculos estreitos). Da última vez, minha solicitação para corrigir a exibição de alguns campos na interface da web do SyncThing resultou em minha edição literal de uma linha em um ambiente que eu não conheço.