Arquitetura Plug and Play

Device-Drivers

Basicamente, a diferença entre desenvolver um device-driver comum e um device-driver plug and play é deixá-lo prevenido contra reconfigurações por parte do sistema operacional. Isto pode ser traduzido por alguns procedimentos de software que se resumem aos recursos exigidos pelo device-driver ficarem sob custódia do sistema operacional (isto para que eles possam ser gerenciados dinamicamente).

Detalhando um pouco mais tal custódia, o device-driver, no instante de seu registro ou instalação, retorna ao sistema operacional um endereço de uma rotina, contida no device-driver, do tipo call-back (como o procedimento de janela ou de caixa de diálogo). Com isso, fica permitida a troca de mensagens entre o sistema operacional e o device-driver. Inclusive, fica o device-driver obrigado a responder a todas as mensagens de reconfiguração enviadas pelo sistema operacional.

A Figura 2 ilustra uma seqüência de comandos que devem estar contidos no código desenvolvido para o device-driver plug and play.

/* variáveis globais do device-driver */
unsigned int interrupção, endereço_base;
  
/* subrotina que recebe as ordens de reconfiguração */
LRESULT CALLBACK device_driver_reconfig( ... )     {
       ...
/* identifica mensagem de reconfiguração */
       ... 
/* altera variáveis globais */
interrupção = ...;
endereço_base = ...; 
altera_manipulador_vetor_interrupção( ... );
      ...
}
  
/* rotinas de acesso ao periférico */
void envia_dado (int dado)    {
outp (endreço_base, dado);      }
  ...  

Figura 2: Exemplo de uma arquitetura de device-driver, contendo a subrotina que intercepta as ordens de reconfiguração e subrotinas de acesso genérico ao periférico.

Concluindo, o processo de configuração de recursos é realizado em duas situações: primeira, por parte da BIOS, durante a inicialização do computador, naturalmente, fazendo parte do POST (Power On Self Test) e, segundo, em tempo de execução, sob gerenciamento do sistema operacional.