Olá, Igor, Ricardo,
2009/5/11 Igor Mol <igor@yrado.com>:
Ainda matenho um pequeno projeto de kernel pessoal e nele aprendi acerca do desenvolvimento de drivers. Mas em sua maioria, utilizei muitos tutoriais para desenvolvê-los, e sei que na maioria das vezes não dispomos de tutoriais para criar drivers específicos em um sistema real.
Normalmente como acontece o processo de criação de um drive real no Linux? É feita uma analise do mesmo através de uma documentação fornecida pelo próprio desenvolvedor, e a partir daí um estudo de como se comunica com a controladora (chip) do dispositivo? Existem exemplos reais disso?
Num mundo ideal, todo hardware tem a documentação fornecida pelo fabricante, e toda ela seria suficiente para escrever o driver. Felizmente isso é o que geralmente acontece, mas há bastante exceções. Às vezes a documentação não é pública, em outros casos a documentação do hardware é pública. Um exemplo de documentação de hardware pública seria a da arquitetura de audio HDA da Intel: http://www.intel.com/standards/hdaudio/ Deve haver muitos outros exemplos de documentação de hardware por aí. O HDA Intel é apenas o que eu lembrei no momento.
Curiosidade: tenho feito um trabalho sobre aplicação do Cálculo na engenharia, e então pensei no desenvolvimento do kernel. Há algum tipo de driver que é necessário o conhecimento de Cálculo para fazê-lo?
É uma boa pergunta. Geralmente um driver apenas traduz serviços que o hardware provê, e torna esses serviços disponíveis para o resto do sistema usar através de alguma interface mais simples e/ou mais controlada. Acho muito difícil um driver exigir conhecimento em Cálculo, principalmente se for possível delegar a tarefa que envolve Cálculo para outro componente do sistema, preferencialmente fora do driver e fora do kernel. On Tue, May 12, 2009 at 10:11:42AM -0300, Ricardo Ayres Severo wrote:
Igor,
eu trabalho no desenvolvimento de sistemas embarcados e já desenvolvi alguns drivers, mas nada muito complexo.
Para desenvolver o driver, nós precisamos saber como que o dispositivo que está conectado ao processador funciona e qual pino do processador corresponde a qual pino do dispositivo. A necessidade de se fazer um driver é para poder acessar esses pinos do processador diretamente, o que não é permitido na userland. O driver então trata os dados para que uma aplicação userland possa utilizar o dispositivo sem se preocupar com o funcionamento específico dele.
O acesso privilegiado não necessariamente é a única razão para drivers estarem dentro do kernel. Mas provavelmente é a razão mais comum.
Todos os drivers que fiz até agora foram char devices, ou seja, a interface do driver com o sistema se dá através de leituras e escritas em um arquivo (um daqueles que ficam em /dev). A maioria dos drivers são assim. Os outros dois tipos são network (sockets) e block devices (HDs e coisas do tipo).
Discordo em parte. A maioria dos drivers não registram char devices ou block devices diretamente. A maioria registra funções em algum subsistema do kernel, implementando as funcionalidades necessárias. A interface entre userspace e o kernel frequentemente é como você falou: através de char devices, block devices & cia. Mas a maioria dos drivers estão atrás de abstrações mais complexas que apenas registrar um char device ou block device, e muitas delas escondem boa parte dos detalhes da interação entre userspace e o kernel. Muitas vezes um driver nem mesmo oferece serviços para userspace, mas apenas serviços que o resto do kernel utiliza, para por sua vez prover algum outro serviço para userspace. Um driver de rede é um exemplo (userspace usa a pilha de rede do kernel, que por sua vez é quem vai utilizar o driver de rede), mas há muitos outros casos parecidos. Por outro lado, registrar um char device ou um block device diretamente pode ser um bom exemplo didático, pela sua simplicidade.
Um livro que recomendo é o Linux Device Drivers, que inclusive está disponível de graça na internet.
-- Eduardo