Muito brevemente:
O mais importante sobre um driver de dispositivo é que ele é executado no espaço do kernel, com as mesmas permissões que o kernel e, portanto, pode acessar o hardware diretamente. As aplicações não são (geralmente) permitidas para fazer isso.
Então, você pode pensar em drivers de dispositivo como partes do kernel que organizam o acesso a determinado hardware (o "dispositivo").
Um aplicativo pode interagir com o kernel em vários níveis: de abstrações mais altas (por exemplo, um sistema de arquivos) a abstrações medianas (um dispositivo de bloco) a abstrações de nível realmente baixo (alguns arquivos em /proc/ ou /sys , alguns ioctls em dispositivos em /dev ). Portanto, as interações de baixo nível às vezes estarão falando diretamente com um driver de dispositivo. Há apenas uma camada muito fina em que o kernel redireciona a chamada para o driver de dispositivo. Portanto, "um aplicativo não pode interagir diretamente com um driver de dispositivo, apenas o sistema operacional pode fazer isso" é uma espécie de verdadeiro e também um pouco falso.
Além disso, há muitas camadas de abstração no kernel, como a que você descreve na imagem ("as mensagens que o SO envia são as mesmas, o driver de dispositivo usa mensagens diferentes para falar com o hardware). Por exemplo, o bloco camada recebe um tipo de mensagens, mas passa-os para diferentes dispositivos de bloco.A camada USB recebe um tipo de mensagens, mas pode usar diferentes controladores de host USB.E assim por diante.
Portanto, a imagem é muito mais difícil, existem camadas e subsistemas no kernel, e os drivers de dispositivos que realmente falam com o hardware estão na parte inferior dessa hierarquia. Para confundir mais as coisas, os drivers de dispositivo e outras camadas vêm na forma de módulos (para Linux). Se você digitar lsmod , poderá ver quais módulos estão ativos e qual módulo usa quais outros módulos.
Além disso, a impressão é um exemplo muito ruim; a maior parte do processamento específico da impressora acontece no espaço do usuário e não em um driver de dispositivo.
Todo o Windows, Linux e MacOS seguem esses princípios, mas os detalhes são muito diferentes.
Isso ajuda?
Editar :
A impressão no Linux geralmente é feita com xícaras . Cups tem uma coleção de programas que podem renderizar documentos para várias impressoras. Todos esses programas pegam um arquivo (o documento como pdf / postscript / ...) e o convertem em outro arquivo em um formato que a impressora entenda. Tudo isso acontece fora do kernel, porque nada disso precisa acessar o hardware real. Apenas lê e grava arquivos. Somente a última parte, quando os dados convertidos são enviados para a impressora, usa o kernel. E então ele pode usar vários caminhos, até mesmo para o mesmo tipo de impressora: via rede, via USB, via conexão serial, etc. E essa última parte geralmente não é específica da impressora.
O Linux não tem drivers de dispositivos específicos para a impressora para a grande maioria das impressoras. (Para algumas impressoras, você pode precisar de uma).