Usando vários módulos do kernel para fazer interface com um dispositivo de hardware?

Question

Estou tentando entender os propósitos que os módulos do kernel podem ter. A motivação para essa questão foi a percepção de que a interface com um hardware real passa por vários módulos do kernel.

Por exemplo, o driver de dispositivo USB tem vários módulos do kernel, onde apenas um é usado para se comunicar com o hardware. ( link )

Qual é o motivo da implementação desta estrutura de "pilha de módulos do kernel"? Isso não apenas complica o processo de fazer com que um dispositivo de hardware funcione (você tem que se preocupar se tem 3 módulos em execução em vez de um)?

    

Answer 1

What is the reason of implementing this "kernel module stack" structure?

É assim que praticamente todo o software é escrito, em pilhas modulares. Considere sua GUI: há todo o espaço do kernel envolvido, incluindo uma pilha de drivers, então no espaço do usuário você tem o servidor X e, acima de tudo, um gerenciador de janelas e, acima de tudo, provavelmente um ambiente desktop. eg) seu navegador.

Essa é uma pilha de software .

O motivo é bastante direto: considere a situação se não houver essa pilha de espaço de usuário. Cada aplicativo GUI teria que escrever seu próprio código de interface com o kernel para acessar a tela, etc. Ficar organizado em relação a outros aplicativos GUI seria completamente voluntário (leia-se: uma séria desordem), a memória do sistema seria completamente preenchida com redundância coisas, e quase ninguém se incomodaria em escrever nada por causa da imensa quantidade de trabalho envolvido.

A situação é exatamente a mesma com os mesmos módulos do kernel. Uma peça que pode ser colocada em mais de um propósito deve ser uma peça independente. Então, WRT para dispositivos USB, em vez de cada driver ter que construir em si mesmo um driver para o controlador USB também, você tem um driver para o controlador e os drivers de dispositivos individuais fazem interface com isso.

Doesn't it just complicate the process?

Não, isso simplifica muito isso. É verdade que você pode ter 3 módulos envolvidos em vez de um, mas se houvesse apenas um, ele teria que implementar as coisas que os outros dois implementam de qualquer maneira.

Existem muitos benefícios para projeto modular e é um inquilino fundamental da engenharia de software. Uma modularidade strong é essencial para evitar o pecado do acoplamento excessivo . Tenho certeza que se você perguntar a alguém que passou muito tempo programando que, à medida que melhorou e se tornou mais competente em projetos maiores e mais complexos, eles se tornaram mais e mais modulares com seu trabalho - ou seja, eles têm cresceu para escrever peças menores e mais discretas. Isso equivale a perceber que você ficará melhor com 3 partes em vez de 1 sempre que fizer sentido (encontrar "onde faz sentido" faz parte da habilidade - quanto mais lugares você puder ver, melhor). sup> 1

Se isso parece ser contra-intuitivo, considere o que acontece se um módulo, bigfoobar , se comportar mal indicando um bug. Descobrir onde ele está será muito mais simples se ele realmente for composto de três partes menores , porque você pode testar independentemente big , foo e bar para determinar qual deles é o culpado . Além disso, foo pode ter um uso geral em outro lugar (por exemplo, como parte de altfoothing , mas observe que as convenções de nomenclatura não funcionam dessa maneira). Quanto mais lugares foo forem usados, mais contextos serão submetidos e mais robustos (funcionais, eficientes, livres de bugs) provavelmente acabarão.

^{1. Quanto mais você olhar em uma pilha, mais você reconhecerá que ela é composta de uma regressão de outras pilhas em uma escala menor e menor. 90% (não me cite) do código do espaço do usuário que sua CPU executa é, na verdade, parte da biblioteca C nativa, que é um executável relativamente pequeno. Isso é parte do que possibilita a execução eficiente de uma ampla variedade de softwares complexos - porque tudo é feito das mesmas poucas pequenas peças. Pense na lego e na diferença entre ter 5 blocos grandes ou 50 menores.}

    

Answer 2

Considere, por exemplo um pendrive USB. Existe um módulo que fala USB (interage com o hardware atual), uma camada que manipula isso como um dispositivo de bloco SCSI, manipulação geral do dispositivo de bloco; e, em seguida, uma camada manipulando o filessytem real que organiza os dados no disco. A maioria deles pode ser módulos reais do kernel do Linux. Outros são camadas que são fixas, mas, no entanto, separadas.

Olhando para isto isoladamente, parece um exagero. Mas tem vários benefícios: Primeiro, se você considerar a distância conceitual entre "Dê-me os primeiros 50 bytes do arquivo foo.txt no dispositivo" e "Alterne os pinos exatamente assim", você verá a necessidade de dividir isso em menores passos para poder compreendê-lo. Segundo, e muito mais importante para os sistemas operacionais em geral, é fatiar a pilha desta maneira, você pode usar a organização de dados exatamente igual ao seu pendrive, um disquete ou uma variedade de discos rígidos. Se um sistema de arquivos diferente aparecer, você poderá misturar e combinar novamente. A mesma coisa para novos tipos de dispositivos (o USB é um recém-chegado ao Linux, esta organização tornou fácil (para algum valor estranho de "fácil", com certeza) adicioná-los perfeitamente).