O que é desejável de um device driver? O deve ser responsabilidade do device driver e o que deve ser deixado por conta do kernel?
Os itens a seguir tendam responder brevemente estas perguntas.
- Flexibilidade:
Um driver é flexível se oferece acesso às capacitações do hardware sem impor restrições a como elas são usadas. O driver deve oferecer, portanto, o mecanismo (quais as funcionalidades oferecidas) independentemente do protocolo (como as funcionalidades podem ser usadas).
É possível ilustrar este conceito usando o exemplo do driver de um leitor de disquetes. O driver é responsável por mostrar um disquete como um array de blocos. Decisões como quem pode acessar os dados do disquete e se o disquete é acessado diretamente ou via file system são de responsabilidade de níveis mais altos do kernel.
Se um driver é flexível, então suas funcionalidades podem ser facilmente adaptadas a necessidades de qualquer software que fazem uso do dispositivo correspondente, tornando-se seu desenvolvimento muito mais simples. Daí a importância deste requisito.
- Operações básicas:
- open: O driver deve oferecer uma operação que inicializa o dispositivo e o deixa apto a executar operações, após verificar erros, mapear suas funcionalidades e eventuais estruturas de dados específicas no kernel, etc. Esta operação é mapeada na system call open();
- release: O driver deve oferecer uma operação que reverte as operações realizadas por open(), ou seja, libera recursos adquiridos e finaliza o dispositivo. Esta operação é mapeada na system call close();
- write & read: O driver deve oferecer uma operação que copia dados do user space para o kernel space e/ou uma operação que copia dados do kernel space para o user space. Estas operações são mapeadas nas system calls write() e read(), respectivamente.
- Operação de bloqueio:
Existem situaçãos nas quais um device driver não puder satisfazer um pedido de imediato do kernel ou outra aplicação? Por exemplo:
- Uma chamada read() pode surgir quando não há dados disponíveis, mas espera-se que haja no futuro;
- Uma chamada write() pode surgir quando o dispositivo estivera indisponível;
- Os buffers do device driver podem estar ocupados.
Nestas situações, o processo responsável deverá bloquear e aguardar que o driver esteja pronto para satisfazer o pedido. Quando isto acontecer, o kernel deverá ser avisado que o processo pode ser desbloqueado.
A responsabilidade do device driver é enviar uma mensagem de bloqueio toda vez que não puder satisfizer um pedido, realizar as operações necessárias para que possa satisfazê-lo (se possível) e enviar outra mensagem avisando que está pronto. Já a gestão de processos é de responsabilidade do kernel.
Da mesma forma, o kernel é responsável por gerir concorrência de processos por um dispositivo. O driver somente responsável por avisar que determinado dispositivo não pode ser comportilhado e está sendo usado por outro processo no momento da chamada.
- Segurança:
Como já foi dito, o device driver deve oferecer a funcionalidade sem protocolo, por isso políticas de segurança devem ser inseridas no código de camadas mais elevadas. A exceção para esta regra são operações que que podem afetar outros processos ou todo o sistema (por exemplo, que geram interrupções).
Um device driver não pode, obviamente, inserir bugs de segurança no sistema, como, por exemplo, erros de buffer overload não tratados
- Outros:
Pode-se pensar em outros requisitos que o device driver deve atender. Por exemplo:
- Capacidade de suportar tanto operações síncronas como assíncronas;
- Habilidade de ser inicializado mais de uma vez;
- Capacidade de explorar o totalidade de capacitações que o dispositivo tem a oferecer;
- Etc…
