Quando um controlador de dispositivo deseja se comunicar com o processador, ele pode enviar uma requisição de interrupção ao processador.
Quando o processador deseja-se comunicar com um controlador de hardware, ele utiliza endereços de portas de entrada/saída. Pois dentro do computador, cada dispositivo físico é representado por seu respectivo controlador. Os controladores de dispositivos físicos possuem endereços que são chamados de portas de entrada/saída. Quando uma instrução de máquina deseja acessar um controlador, um dos operandos dessa instrução deve ser o endereço (porta) do controlador. No Linux, o "arquivo" proc/ioports contém uma lista de endereços de controladores que podem ser acessados pelo processador. Note que quando o controlador deseja se comunicar com o processador, a comunicação ocorrerá através das interrupções e não pelas portas de entrada/saída.
Controladores de dispositivos não são componentes do Sistema Operacional, os controladores são hardware e podem estar na placa mãe do computador ou em placas dedicadas. Eles "sabem conversar" com os dispositivos propriamente ditos (ex. SSD). Por exemplo, a placa de vídeo é um tipo de controlador e o monitor é o dispositivo físico.
Quando um processador recebe uma requisição de interrupção, os circuitos do processador suspendem seu fluxo de execução corrente e desviam para um endereço pré-definido onde se encontra uma rotina de tratamento de interrupção (interrupt handler). Essa rotina de tratamento é responsável por tratar a interrupção, ou seja, executar as ações necessárias para atender a interrupção gerada pelo dispositivo. Ao final da rotina de tratamento da interrupção, o processador retorna o código que estava executando quando recebeu a requisição. Para ver uma lista de interrupções tratadas pelos núcleos do processador, execute, no Linux, o comando # cat /proc/interrupts
Os drivers de dispositivos são responsáveis por interagir com os controladores de dispositivos. Já que a comunicação entre o SO e os controladores de dispositivos ocorrem por meio dos drivers. Cada driver tem o conhecimento do controlador de dispositivo ao qual ele está associado. Eles podem ser executados como módulos do SO e, quando são carregados, passam a ter acesso às variáveis e funções do Kernel (no caso de um SO monolítico ou híbrido, por exemplo).
Cada SO (Windows e Linux, por exemplo) possui seu próprio conjunto de chamadas de sistema (syscalls). As chamadas de sistemas são específicas de cada sistema operacional. As bibliotecas que você utiliza em um programa em C, por exemplo, conhecem as syscalls do SO. Por este motivo, o mesmo programa executável não roda no Windows e Linux.
Quando um controlador de dispositivo deseja se comunicar com o processador, ele pode enviar uma requisição de interrupção ao processador. O controlador pode se comunicar com o processador de duas maneiras: 1) aguardar até que o processador o consulte, o que poderá ser demorado caso o processador esteja ocupado com outras tarefas, o que geralmente ocorre; 2) notificar o processador, enviando a ele uma requisição de interrupção (IRQ - Interrupt ReQuest) através do barramento de controle.
As flags que definem o nível de privilégio só podem ser modificados por código executando no nível núcleo, o que impede usuários maliciosos de contornar essa barreira de proteção. Para realizar a operação de entrada/saída, o processo deve executar uma chamada de sistema. A execução da chamada de sistema (mais especificamente, da instrução syscall) troca o nível de privilégio do processador para que a operação de entrada/saída seja executada.
Interrupções de hardware que se comunicam com os dispositivos físicos executam no modo kernel. Como os drivers possuem esse tipo de instrução, eles devem operar no modo kernel. Note que, isso é muito importante pois é o Sistema Operacional que gerencia o acesso ao hardware. Se os programas de usuário pudessem acessar ao hardware diretamente, sem o conhecimento do Sistema Operacional, como a gerência dos recursos de hardware poderia ocorrer? O SO, por exemplo, gerencia a fila processos que desejam escrever em um SSD.
O processador de um computador típico pode operar no modo usuário ou no modo kernel (ou modo sistema). Os processadores de computadores típicos têm pelo menos esses dois modos de operação. Os processos de usuário executam no modo usuário e, por isso, têm acesso a um subconjunto de instruções seguras. Já os processos do SO, executam no modo kernel e, por isso, tem acesso a todo o hardware por meio das instruções de I/O. O código de uma chamada de sistema, por exemplo, têm acesso a todo o hardware pois ele executa no modo kernel.
Em um SO típico (ex. Linux, Windows), quando um aplicativo deseja acessar um arquivo em um dispositivo de armazenamento, o aplicativo se comunica com o sistema de arquivos (que é um componente do kernel do SO), que por sua vez se comunica com o driver. O driver interage com a controladora de disco que, por fim, interage com o disco. Esses passos descrevem, de forma geral, como ocorre a comunicação entre um processo de usuário e o hardware.
COMENTÁRIOS