Compartilhar via

Vantagens de escrever drivers UMDF

  • Artigo

Este tópico descreve as vantagens de escrever um driver um User-Mode Driver Framework (UMDF) em vez de um driver no modo kernel.

Ao escrever um driver UMDF, você se beneficia do seguinte:

  • Os drivers UMDF contribuem para maior estabilidade do sistema operacional porque têm acesso apenas ao espaço de endereço do processo em que são executados.

  • Como os drivers UMDF são executados na conta LocalService , eles têm acesso limitado aos dados de um usuário ou aos arquivos do sistema.

  • Os drivers de modo de usuário operam em um ambiente muito mais simples do que os drivers no modo kernel. Por exemplo, os drivers do modo kernel devem levar em conta o IRQL, as falhas de página e o contexto do thread. No modo de usuário, no entanto, esses problemas não existem. Os drivers de modo de usuário sempre são executados em um thread diferente do processo de solicitação e sempre podem receber falhas de página.

  • O UMDF versão 2 oferece paridade de recursos com KMDF na maioria das áreas. Para obter uma comparação completa, consulte Comparando a funcionalidade do UMDF 2 com o KMDF.

  • O UMDF versão 2 facilita a conversão entre KMDF e UMDF. Confira Como converter um driver KMDF em um driver UMDF 2 (e vice-versa).

  • Você pode depurar drivers UMDF usando um depurador de modo de usuário ou, começando com UMDF versão 2, um depurador no modo kernel.

  • Você pode usar os comandos de extensão Wdfkd.dll depurador com KMDF e começar com UMDF versão 2. Para obter mais informações, consulte Extensões do Depurador.

Uma meta fundamental do modelo geral do WDF é fornecer padrões inteligentes, para que você possa se concentrar no hardware do dispositivo e evitar escrever código para executar tarefas comuns à maioria dos drivers.

Para atingir essa meta, a estrutura foi projetada para trabalhar com drivers em uma base de "aceitação". Ao escrever um driver UMDF, você fornece rotinas de retorno de chamada apenas para os eventos que afetam seu dispositivo. Por exemplo, alguns dispositivos exigem intervenção imediatamente após serem ativados e pouco antes de serem desativados. O driver para esse dispositivo pode implementar funções de retorno de chamada que a estrutura chama nesses momentos.

O driver inclui código para lidar apenas com os eventos para os quais seu dispositivo requer suporte específico ao dispositivo. Todos os outros eventos podem ser tratados por padrões de estrutura.

Além disso, um driver pode configurar suas filas de solicitação de E/S para que a estrutura pare de expedir solicitações enquanto o dispositivo estiver em um estado de baixa potência e retome a expedição depois que o dispositivo retornar ao estado operacional. Da mesma forma, se uma solicitação de E/S chegar enquanto o dispositivo estiver em um estado de baixa potência, a estrutura poderá ativar automaticamente o dispositivo.