faz um programa do usuário sempre usar chamadas do sistema para acessar um driver de dispositivo

Question

No Linux, um programa do usuário sempre usa chamadas do sistema para o kernel do SO, para acessar um driver de dispositivo indiretamente?

Quando o driver é implementado como um módulo que pode ser carregado e descarregado, um programa do usuário acessa o driver diretamente sem fazer uma chamada ao kernel?

    

Answer 1

O usuário chama funções de biblioteca que envolvem as chamadas do sistema (o syscall bruto é bastante raro para um programador normal). O código do módulo é executado no modo kernel, portanto, em algum momento, deve haver uma alternância de contexto do espaço do usuário para o espaço do kernel. Idealmente, a maioria dos módulos usará interfaces padronizadas (nós de dispositivos, sockets de netlink, até sockets de inet), para que a interação do lado do usuário seja principalmente através de read() e write() chamadas de sistema ( ioctl também é bastante comum, como abrange as configurações "extras" que não se enquadram nas chamadas padrão do sistema. Os buffers diminuirão o número de chamadas, mas no final sempre há uma chamada de sistema envolvida.

    

Answer 2

Os módulos do kernel existem no espaço do kernel e, portanto, por definição, requerem chamadas do sistema para serem acessados do espaço do usuário, portanto, sim em relação a eles.

No entanto, é possível criar drivers de espaço de usuário que são construídos em cima de um kernel, embora no final eles devam fazer chamadas de sistema para operar. Isto é possível com, por exemplo, dispositivos I ² C; o driver do userspace usa a API do SMBus do kernel (que é todas as chamadas do sistema). Nesse caso, algum aplicativo pode tecnicamente usar algum recurso do driver sem passar pelo sistema, mas se o driver realmente interagir com o hardware, as chamadas do sistema serão feitas novamente.

Também é possível usar mmap() (uma chamada de sistema) em /dev/mem , que é a memória do sistema (consulte man mem ) e, como isso inclui todo o espaço do kernel, expõe o acesso ao hardware. Manipulando este mapa então não requer mais chamadas do sistema. Acredito que isso seja uma coisa incomum, parcialmente porque ele evita o próprio kernel de uma maneira que pode ser indesejável, e parcialmente porque torná-lo portátil de uma arquitetura para outra envolveria redundância ¹ - assim é mais provável que seja usado para hacking e experimentação do que a implantação de drivers em sistemas de produção.

Os drivers do kernel podem expor uma interface baseada no nó do dispositivo para o usuário, que pode ser operada usando read() e write() - que são chamadas do sistema.

^{1. Se você escreve um driver de kernel normal, ou usa uma API de usuário do kernel, o próprio kernel cobre problemas de portabilidade; você pode ficar com uma versão do seu código. Se você usar o método de mapeamento de memória, terá que ter diferentes versões de seu código para cada arquitetura (que o kernel já possui, portanto, "redundante").}