[kernel-br] Desenvolvimento de Drivers

[Eduardo Habkost]

Olá, Igor, Ricardo,

> 2009/5/11 Igor Mol <igor em 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