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.
