1.. SPDX-License-Identifier: GPL-2.0 2 3A interface de drivers do kernel Linux 4======================================= 5 6(todas as suas perguntas respondidas e mais algumas) 7 8Greg Kroah-Hartman <greg@kroah.com> 9 10Este texto foi escrito para tentar explicar por que o Linux **não possui uma 11interface binária do kernel nem uma interface estável do kernel**. 12 13.. note:: 14 15 Observe que este artigo descreve as interfaces **internas do kernel**, e não 16 as interfaces entre o kernel e o espaço de usuário. 17 18 A interface entre o kernel e o espaço de usuário é aquela utilizada pelos 19 aplicativos: a interface de chamadas de sistema (syscalls). Essa 20 interface é **muito** estável ao longo do tempo e não será quebrada. Tenho 21 programas antigos, compilados em uma versão do kernel anterior à 0.9 e alguma 22 coisa, que ainda funcionam perfeitamente na versão mais recente do kernel 23 2.6. Essa é a interface cuja estabilidade os usuários e desenvolvedores de 24 aplicativos podem considerar garantida. 25 26 27Resumo executivo 28---------------- 29 30Você acha que quer uma interface estável do kernel, mas, na verdade, não quer, 31e nem sabe disso. O que você realmente quer é um driver que continue 32funcionando de maneira estável, e isso só é possível se o seu driver estiver 33na árvore principal do kernel. Você também obtém muitos outros benefícios se 34o seu driver fizer parte da árvore principal do kernel. São esses benefícios 35que ajudaram a tornar o Linux um sistema operacional tão robusto, estável e 36maduro — justamente a razão pela qual você o está usando. 37 38 39Introdução 40---------- 41 42Apenas quem escreve drivers para o kernel precisa se preocupar com as mudanças 43nas interfaces internas do kernel. Para a grande maioria das pessoas, essas 44interfaces nem sequer são visíveis e tampouco são motivo de preocupação. 45 46Antes de mais nada, não abordarei **nenhuma** questão jurídica relacionada a 47código-fonte fechado, código-fonte oculto, blobs binários, wrappers de 48código-fonte ou qualquer outro termo usado para descrever drivers do kernel 49cujo código-fonte não seja disponibilizado sob a GPL. Consulte um advogado 50caso tenha alguma dúvida jurídica. Sou programador e, portanto, descreverei 51aqui apenas as questões técnicas (isso não significa que as questões 52jurídicas sejam pouco importantes; elas são reais e você precisa estar sempre 53ciente delas). 54 55Portanto, há dois tópicos principais: interfaces binárias do kernel e 56interfaces estáveis de código-fonte do kernel. Ambos dependem um do outro, 57mas discutiremos primeiro a parte referente às interfaces binárias para 58deixá-la de lado. 59 60 61Interface binária do kernel 62--------------------------- 63 64Supondo que tivéssemos uma interface estável de código-fonte para o kernel, 65uma interface binária surgiria naturalmente também, certo? Errado. Considere 66os seguintes fatos sobre o kernel Linux: 67 68 - Dependendo da versão do compilador C utilizada, diferentes estruturas de 69 dados do kernel terão diferentes alinhamentos e poderão até mesmo incluir 70 funções de maneiras distintas (por exemplo, tornando determinadas funções 71 inline ou não). A organização das funções individuais não é tão importante, 72 mas as diferenças no preenchimento das estruturas de dados são muito 73 importantes. 74 - Dependendo das opções selecionadas durante a compilação do kernel, uma 75 grande variedade de comportamentos pode ser assumida pelo kernel: 76 77 - diferentes estruturas podem conter campos diferentes; 78 - algumas funções podem nem sequer ser implementadas (por exemplo, 79 determinados bloqueios são completamente eliminados durante a 80 compilação em kernels sem SMP); 81 - a memória dentro do kernel pode ser alinhada de maneiras diferentes, 82 dependendo das opções de compilação. 83 - O Linux é executado em uma grande variedade de arquiteturas de 84 processadores. Não há como drivers binários compilados para uma arquitetura 85 funcionarem corretamente em outra. 86 87Vários desses problemas podem ser contornados simplesmente compilando o módulo 88para uma configuração específica e exata do kernel, utilizando exatamente o 89mesmo compilador C empregado na compilação do kernel. Isso é suficiente caso 90você queira fornecer um módulo para uma determinada versão de uma distribuição 91Linux específica. Porém, multiplique essa única compilação pelo número de 92distribuições Linux existentes e pelo número de versões suportadas de cada 93distribuição e você rapidamente terá um pesadelo de diferentes opções de 94compilação em diferentes versões. Além disso, cada versão de uma distribuição 95Linux contém vários kernels, cada um ajustado para diferentes tipos de 96hardware (diferentes tipos de processadores e diferentes opções). Portanto, 97mesmo para uma única versão, você precisará criar várias versões do seu módulo. 98 99Acredite em mim: com o tempo, você enlouquecerá se tentar oferecer suporte a 100esse tipo de distribuição. Aprendi isso da maneira mais difícil há muito 101tempo... 102 103Interfaces estáveis de código-fonte do kernel 104---------------------------------------------- 105 106Esse é um tópico um pouco mais "volátil" se você conversar com alguém que está 107tentando manter atualizado, ao longo do tempo, um driver do kernel Linux que 108não está na árvore principal do kernel. 109 110O desenvolvimento do kernel Linux é contínuo e ocorre em ritmo acelerado, 111sem desacelerar. Por isso, os desenvolvedores do kernel encontram bugs nas 112interfaces existentes ou descobrem maneiras melhores de fazer as coisas. 113Quando isso acontece, eles corrigem as interfaces atuais para que funcionem 114melhor. Nesse processo, nomes de funções podem mudar, estruturas podem crescer 115ou diminuir e parâmetros de funções podem ser reformulados. Quando isso 116acontece, todos os locais dentro do kernel que utilizam essa interface são 117corrigidos ao mesmo tempo, garantindo que tudo continue funcionando 118corretamente. 119 120Como exemplos específicos disso, as interfaces USB internas do kernel 121passaram por pelo menos três reformulações diferentes ao longo da existência 122desse subsistema. Essas reformulações foram feitas para resolver diversos 123problemas: 124 125 - Uma mudança de um modelo síncrono de fluxos de dados para um modelo 126 assíncrono. Isso reduziu a complexidade de vários drivers e aumentou a 127 taxa de transferência de todos os drivers USB, de modo que atualmente 128 executamos quase todos os dispositivos USB na maior velocidade possível. 129 - Foi feita uma mudança na maneira como os pacotes de dados eram alocados 130 pelos drivers USB a partir do núcleo USB, de modo que todos os drivers 131 passaram a precisar fornecer mais informações ao núcleo USB, corrigindo 132 diversos deadlocks documentados. 133 134Isso contrasta fortemente com vários sistemas operacionais de código fechado, 135que tiveram de manter suas interfaces USB antigas ao longo do tempo. Isso 136permite que novos desenvolvedores utilizem acidentalmente interfaces antigas 137e façam as coisas de maneira inadequada, prejudicando a estabilidade do 138sistema operacional. 139 140Em ambos os casos, todos os desenvolvedores concordaram que essas eram 141mudanças importantes que precisavam ser feitas, e elas foram realizadas com 142relativamente pouco esforço. Se o Linux tivesse de garantir a preservação de 143uma interface de código-fonte estável, uma nova interface teria de ser criada, 144enquanto a interface antiga e defeituosa teria de continuar sendo mantida ao 145longo do tempo, resultando em trabalho adicional para os desenvolvedores USB. 146Como todos os desenvolvedores USB do Linux realizam esse trabalho em seu 147próprio tempo, pedir que programadores façam trabalho extra, sem nenhum 148benefício e gratuitamente, não é uma possibilidade. 149 150Questões de segurança também são muito importantes para o Linux. Quando um 151problema de segurança é encontrado, ele é corrigido em um período muito curto. 152Em diversas ocasiões, isso fez com que interfaces internas do kernel fossem 153reformuladas para impedir que o problema de segurança ocorresse. Quando isso 154acontece, todos os drivers que utilizam essas interfaces também são corrigidos 155ao mesmo tempo, garantindo que o problema de segurança seja resolvido e não 156possa reaparecer acidentalmente no futuro. Se as interfaces internas não 157pudessem ser alteradas, não seria possível corrigir esse tipo de problema de 158segurança e garantir que ele não voltasse a ocorrer. 159 160As interfaces do kernel são aprimoradas ao longo do tempo. Se ninguém estiver 161utilizando uma determinada interface, ela é removida. Isso garante que o 162kernel permaneça o menor possível e que todas as interfaces existentes possam 163ser testadas da melhor maneira possível (é praticamente impossível testar 164adequadamente a validade de interfaces que não são utilizadas). 165 166 167O que fazer 168----------- 169 170Então, se você possui um driver do kernel Linux que não está na árvore 171principal do kernel, o que você, como desenvolvedor, deve fazer? Distribuir 172um driver binário para cada versão diferente do kernel em cada distribuição 173é um pesadelo, e tentar acompanhar uma interface do kernel que está em 174constante mudança também é uma tarefa difícil. 175 176Simples: coloque seu driver na árvore principal do kernel (lembre-se de que 177estamos falando aqui de drivers distribuídos sob uma licença compatível com 178a GPL; se seu código não se enquadra nessa categoria, boa sorte, você está 179por conta própria aqui, seu parasita). Se seu driver estiver na árvore e uma 180interface do kernel mudar, ele será corrigido pela própria pessoa que realizou 181a alteração no kernel. Isso garante que seu driver continue sempre compilável 182e funcionando ao longo do tempo, exigindo muito pouco esforço de sua parte. 183 184Os excelentes efeitos colaterais de ter seu driver na árvore principal do 185kernel são: 186 187 - A qualidade do driver aumentará, enquanto os custos de manutenção 188 (para o desenvolvedor original) diminuirão. 189 - Outros desenvolvedores adicionarão funcionalidades ao seu driver. 190 - Outras pessoas encontrarão e corrigirão bugs no seu driver. 191 - Outras pessoas encontrarão oportunidades de otimização no seu driver. 192 - Outras pessoas atualizarão o driver para você quando mudanças em 193 interfaces externas exigirem isso. 194 - O driver será automaticamente distribuído por todas as distribuições 195 Linux, sem que seja necessário pedir às distribuições que o adicionem. 196 197Como o Linux oferece suporte, "pronto para uso", a um número maior de 198dispositivos diferentes do que qualquer outro sistema operacional, e oferece 199suporte a esses dispositivos em mais arquiteturas de processadores diferentes 200do que qualquer outro sistema operacional, esse modelo comprovado de 201desenvolvimento deve estar fazendo alguma coisa certa :) 202 203 204------ 205 206Agradecimentos a Randy Dunlap, Andrew Morton, David Brownell, Hanna Linder, 207Robert Love e Nishanth Aravamudan pela revisão e pelos comentários sobre 208este documento. 209