Informações gerais sobre suporte para dispositivos de plug & play

Depois que o BIOS identificar a drageira, a placa de vídeo e o teclado, ela está pronta para começar a inicializar (carregando o sistema operacional na memória do disco rígido). Se você disse ao BIOS que tem um sistema operacional PNP (PNP OS), ele deve começar a inicializar o PC como acima e deixar o sistema operacional terminar o PNP Configurando. Caso contrário, um PNP-BIOS (antes da inicialização) provavelmente tentará fazer o restante do PNP configurando os dispositivos (mas não informará os drivers de dispositivo sobre o que ele fez). Mas os motoristas ainda podem descobrir isso utilizando funções disponíveis no kernel Linux.

Os dispositivos Plug and Play precisam de drivers?

Se você não entende esta seção, leia os dispositivos de hardware da próxima seção e comunicação com eles

Explicação simplificada, plug-and-play diz ao software (drivers de dispositivo) onde encontrar várias peças de hardware (dispositivos), como modems, cartões de rede, cartões de som, etc. A tarefa do plug-and-play é combinar dispositivos físicos com o software (drivers de dispositivo) que opera e estabelecer canais de comunicação entre cada dispositivo físico e seu driver. Para conseguir isso, o PNP aloca e define os seguintes “recursos de barramento” em hardware: endereços de E/S, regiões de memória, IRQs, canais DMA (somente ônibus LPC e ISA). Às vezes, essas 4 coisas são chamadas de “recursos de 1ª ordem” ou apenas “recursos”. O PNP mantém um registro do que é feito e permite que os drivers de dispositivo obtenham essas informações. Se você não entende o que são esses 4 recursos de barramento, leia as seguintes subseções deste Howto: E/S Endereços, IRQs, canais DMA, regiões de memória. Um artigo no Linux Gazette sobre 3 desses recursos de barramento é a introdução de IRQs, DMAs e endereços básicos. Uma vez que essas recursos de barramento foram atribuídas (e se o driver correto estiver instalado), o driver real e os “arquivos” para ele no diretório /dev estiverem prontos para usar.

Esta atribuição de PNP de recursos de barramento às vezes é chamada de “configuração”, mas é apenas um tipo de baixo nível de configuração. O diretório /etc. possui muitos arquivos de configuração, mas a maioria de todos eles não são para configuração de PNP. Portanto, a maior parte da configuração de dispositivos de hardware não tem nada a ver com PNP ou RESOURCES DE BUS. Por exemplo, a inicialização de um modem por uma “string init” ou definindo sua velocidade não é PNP. Assim, ao falar sobre PNP, “configurar” significa apenas um certo tipo de configuração. Enquanto outra documentação (como para o MS Windows) simplesmente chama os recursos de barramento de “recursos”, às vezes uso o termo “resistência ao barramento” em vez de apenas “recursos”, a fim de distingui-lo da multidão de outros tipos de recursos.

PNP é um processo feito por vários softwares e hardware. Se houvesse apenas um programa que lidou com o PNP no Linux, seria simples. Mas com o Linux, cada driver de dispositivo faz seu próprio PNP, usando o software fornecido pelo kernel. O hardware do BIOS do PC faz PNP quando um PC é ligado pela primeira vez. E há muito mais do que isso.

Um computador consiste em uma CPU/processador para fazer a computação e a memória RAM para armazenar programas e dados (para acesso rápido). Além disso, existem vários dispositivos, como vários tipos de disco de disco, uma placa de vídeo, um teclado, dispositivos de rede, cartões modernos, dispositivos de som, barramento USB, portas serial e paralelas, etc. Antigamente, a maioria dos dispositivos estava em cartões inseridos em slots no PC. Hoje, muitos dispositivos que antes eram cartões agora estão a bordo, pois estão contidos em fichas na placa-mãe. Há também uma fonte de alimentação para fornecer energia elétrica, vários ônibus em uma placa -mãe para conectar os dispositivos à CPU e um caso para colocar tudo isso em.

Cartões que se conectam à placa -mãe podem conter mais de um dispositivo. Às vezes, os chips de memória também são considerados dispositivos, mas não são plug-and-play no sentido usado neste Howto.

Para que o sistema de computador funcione corretamente, cada dispositivo deve estar sob o controle de seu “driver de dispositivo”. Este é um software que faz parte do sistema operacional (talvez carregado como módulo) e é executado na CPU. Os drivers de dispositivo estão associados a “arquivos especiais” no diretório /dev, embora não sejam realmente arquivos. Eles têm nomes como HDA3 (terceira partição no disco rígido A), TTYS1 (a segunda porta serial), ETH0 (o primeiro cartão Ethernet), etc.

O dispositivo ETH0 é para um cartão Ethernet (cartão NIC). Anteriormente era /dev /eth0, mas agora é apenas um dispositivo virtual no kernel. O que o ETH0 se refere depende do tipo de cartão Ethernet que você tem. Se o motorista for um módulo, essa tarefa é provável em uma tabela interna do kernel, mas pode ser encontrada em /etc /módulos.conf (chamado “alias”). Por exemplo, se você tiver um cartão Ethernet que usa o chip “tulip” que você pode colocar “alias eth0 tulip” em /etc /módulos.conf para que, quando seu computador pede eth0, ele encontra o driver de tulipa. No entanto, os kernels modernos geralmente podem encontrar o módulo de driver certo para que você raramente precise especificar você mesmo.

Para controlar um dispositivo, a CPU (sob o controle do driver do dispositivo) envia comandos e dados para e lê status e dados dos vários dispositivos. Para fazer isso, cada driver de dispositivo deve conhecer o endereço do dispositivo que controla. Saber esse endereço é equivalente a configurar um canal de comunicação, mesmo que o “canal” físico seja realmente o barramento de dados dentro do PC, que é compartilhado com muitos outros dispositivos.

Este canal de comunicação é realmente um pouco mais complexo do que o descrito acima. Um “endereço” é na verdade uma variedade de endereços, então às vezes a palavra “intervalo” é usada em vez de “endereço”. Pode até haver mais de um intervalo (sem sobreposição) para um único dispositivo. Além disso, há uma parte reversa do canal (conhecida como interrupções) que permite que os dispositivos enviem uma solicitação urgente de “ajuda” para o driver do dispositivo.

O barramento PCI possui 3 espaços de endereço: E/S, memória principal (memória IO) e configuração.


Informações gerais sobre suporte para dispositivos de plug & play

Depois que o BIOS identificar a drageira, a placa de vídeo e o teclado, ela está pronta para começar a inicializar (carregando o sistema operacional na memória do disco rígido). Se você disse ao BIOS que tem um sistema operacional PNP (PNP OS), ele deve começar a inicializar o PC como acima e deixar o sistema operacional terminar o PNP Configurando. Caso contrário, um PNP-BIOS (antes da inicialização) provavelmente tentará fazer o restante do PNP configurando os dispositivos (mas não informará os drivers de dispositivo sobre o que ele fez). Mas os motoristas ainda podem descobrir isso utilizando funções disponíveis no kernel Linux.

Os dispositivos Plug and Play precisam de drivers?

Se você não entende esta seção, leia os dispositivos de hardware da próxima seção e comunicação com eles

Explicação simplificada, plug-and-play diz ao software (drivers de dispositivo) onde encontrar várias peças de hardware (dispositivos), como modems, cartões de rede, cartões de som, etc. A tarefa do plug-and-play é combinar dispositivos físicos com o software (drivers de dispositivo) que opera e estabelecer canais de comunicação entre cada dispositivo físico e seu driver. Para conseguir isso, o PNP aloca e define os seguintes “recursos de barramento” em hardware: endereços de E/S, regiões de memória, IRQs, canais DMA (somente ônibus LPC e ISA). Às vezes, essas 4 coisas são chamadas de “recursos de 1ª ordem” ou apenas “recursos”. O PNP mantém um registro do que é feito e permite que os drivers de dispositivo obtenham essas informações. Se você não entende o que são esses 4 recursos de barramento, leia as seguintes subseções deste Howto: E/S Endereços, IRQs, canais DMA, regiões de memória. Um artigo no Linux Gazette sobre 3 desses recursos de barramento é a introdução de IRQs, DMAs e endereços básicos. Uma vez que essas recursos de barramento foram atribuídas (e se o driver correto estiver instalado), o driver real e os “arquivos” para ele no diretório /dev estiverem prontos para usar.

Esta atribuição de PNP de recursos de barramento às vezes é chamada de “configuração”, mas é apenas um tipo de baixo nível de configuração. O diretório /etc. possui muitos arquivos de configuração, mas a maioria de todos eles não são para configuração de PNP. Portanto, a maior parte da configuração de dispositivos de hardware não tem nada a ver com PNP ou RESOURCES DE BUS. Pois, exemplo, a inicialização de um modem por uma “string init” ou configuração de sua velocidade não é pnp. Assim, ao falar sobre PNP, “configurar” significa apenas um certo tipo de configuração. Enquanto outra documentação (como para o MS Windows) simplesmente chama os recursos de barramento de “recursos”, às vezes uso o termo “resistência ao barramento” em vez de apenas “recursos”, a fim de distingui-lo da multidão de outros tipos de recursos.

PNP é um processo feito por vários softwares e hardware. Se houvesse apenas um programa que lidou com o PNP no Linux, seria simples. Mas com o Linux cada driver de dispositivo faz seu próprio PNP, usando o software fornecido pelo kernel. O hardware do BIOS do PC faz PNP quando um PC é ligado pela primeira vez. E há muito mais do que isso.

Um computador consiste em uma CPU/processador para fazer a computação e a memória RAM para armazenar programas e dados (para acesso rápido). Além disso, existem vários dispositivos, como vários tipos de disco de disco, uma placa de vídeo, um teclado, dispositivos de rede, cartões modernos, dispositivos de som, barramento USB, portas serial e paralelas, etc. Antigamente, a maioria dos dispositivos estava em cartões inseridos em slots no PC. Hoje, muitos dispositivos que antes eram cartões, agora estão a bordo, pois estão contidos em fichas na placa-mãe. Há também uma fonte de alimentação para fornecer energia elétrica, vários ônibus em uma placa -mãe para conectar os dispositivos à CPU e um caso para colocar tudo isso em.

Cartões que se conectam à placa -mãe podem conter mais de um dispositivo. Às vezes, os chips de memória também são considerados dispositivos, mas não são plug-and-play no sentido usado neste Howto.

Para que o sistema de computador funcione corretamente, cada dispositivo deve estar sob o controle de seu “driver de dispositivo”. Este é um software que faz parte do sistema operacional (talvez carregado como módulo) e é executado na CPU. Os drivers de dispositivo estão associados a “arquivos especiais” no diretório /dev, embora não sejam realmente arquivos. Eles têm nomes como HDA3 (terceira partição no disco rígido A), TTYS1 (a segunda porta serial), ETH0 (o primeiro cartão Ethernet), etc.

O dispositivo ETH0 é para um cartão Ethernet (cartão NIC). Anteriormente era /dev /eth0, mas agora é apenas um dispositivo virtual no kernel. O que o ETH0 se refere depende do tipo de cartão Ethernet que você tem. Se o motorista for um módulo, essa tarefa é provável em uma tabela interna do kernel, mas pode ser encontrada em /etc /módulos.conf (chamado “alias”). Por exemplo, se você tiver um cartão Ethernet que usa o chip “tulip” que você pode colocar “alias eth0 tulip” em /etc /módulos.conf para que, quando seu computador pede eth0, ele encontra o driver de tulipa. No entanto, os kernels modernos geralmente podem encontrar o módulo de driver certo para que você raramente precise especificar você mesmo.

Para controlar um dispositivo, a CPU (sob o controle do driver do dispositivo) envia comandos e dados para e lê status e dados dos vários dispositivos. Para fazer isso, cada driver de dispositivo deve saber o endereço do dispositivo que controla. Saber esse endereço é equivalente a configurar um canal de comunicação, mesmo que o “canal” físico seja realmente o barramento de dados dentro do PC, que é compartilhado com muitos outros dispositivos.

Este canal de comunicação é realmente um pouco mais complexo do que o descrito acima. Um “endereço” é na verdade uma variedade de endereços para que às vezes a palavra “intervalo” seja usada em vez de “endereço”. Pode até haver mais do que um intervalo (sem sobreposição) para um único dispositivo. Além disso, há uma parte reversa do canal (conhecida como interrupções) que permite que os dispositivos enviem uma solicitação urgente de “ajuda” para o driver do dispositivo.

O barramento PCI possui 3 espaços de endereço: E/S, memória principal (memória IO) e configuração. O antigo ônibus Isa não possui um espaço de endereço de “configuração” genuíno. Apenas os espaços de memória I/0 e IO são usados ​​para o dispositivo io. Os endereços de configuração são fixos e não podem ser alterados para que não precisem ser alocados. Para mais detalhes, consulte o espaço de endereço de configuração do PCI

Quando a CPU deseja acessar um dispositivo, ele coloca o endereço do dispositivo em um barramento principal do computador (para PCI: o endereço/barramento de dados). Todos os tipos de endereços (como E/S e memória principal) compartilham o mesmo barramento dentro do PC. Mas a presença ou ausência de tensão em certos fios dedicados no barramento do PC informa qual “espaço” um endereço está em: E/S, memória principal (consulte Ranges de memória) ou configuração (somente PCI). Isso é um pouco simplificado demais, pois disse a um dispositivo PCI que é um acesso ao espaço de configuração é realmente mais complexo do que descrito acima. Consulte o espaço de endereço de configuração do PCI para obter detalhes. Consulte Detalhes do endereço para obter mais detalhes sobre o abordagem em geral.

Os endereços de um dispositivo são armazenados em seus registros no dispositivo físico. Eles podem ser alterados por software e podem ser desativados para que o dispositivo não tenha endereço. Exceto que o endereço de configuração do PCI não pode ser alterado ou desativado.

Os dispositivos foram originalmente localizados no espaço de endereço de E/S, mas hoje eles podem usar espaço na memória principal. Um endereço I/0 às vezes é chamado de “E/O”, “IO”, “E/O” ou “IO”. Os termos “porta de E/S” ou “intervalo de E/S” também são usados. Não confunda essas portas de IO com a “Memory IO” localizada na memória principal. Existem duas etapas principais para alocar os endereços de E/S (ou alguns outros recursos de ônibus, como interrupções no barramento ISA):

  1. Defina o endereço de E/S, etc. no hardware (em um de seus registros)
  2. Informe o driver do dispositivo que saiba o endereço de E/S, etc. é

Freqüentemente, o driver do dispositivo faz ambos (mais ou menos). O driver do dispositivo não precisa definir um endereço de E/S se descobrir que o endereço foi definido anteriormente (talvez pelo BIOS) e está disposto a aceitar esse endereço. Depois que o motorista descobriu qual endereço foi definido anteriormente ou define o endereço em si, então ele obviamente sabe qual é o endereço, para que não haja necessidade de informar o motorista ao endereço -já sabe.

O processo de duas etapas acima (1. Defina o endereço no hardware. 2. Deixe o motorista saber isso.) é algo como o problema de duas partes de encontrar o número da casa de alguém em uma rua. Alguém deve instalar um número na frente da casa para que ela possa ser encontrada e, em seguida, as pessoas que desejam ir para este endereço devem obter (e anotar) este número de casa para que possam encontrar a casa. Para os computadores, o hardware do dispositivo deve primeiro colocar seu endereço em um registro especial em seu hardware (coloque o número da casa) e, em seguida, o driver do dispositivo deve obter esse endereço (escreva o número da casa em seu livro de endereços). Ambos devem ser feitos, automaticamente por software ou inserindo os dados manualmente em arquivos de configuração. Problemas podem ocorrer quando apenas um deles é feito corretamente.

Para configuração manual do PNP, algumas pessoas cometem o erro de fazer apenas uma dessas duas etapas e depois se perguntam por que o computador não consegue encontrar o dispositivo. Por exemplo, eles podem usar “SetSerial” para atribuir um endereço a uma porta serial sem perceber que isso apenas informa ao motorista um endereço. Ele não define o endereço no próprio hardware da porta serial. Se você disse ao motorista errado, então está com problemas. Outra maneira de dizer ao driver é dar o endereço como uma opção a um módulo de kernel (driver de dispositivo). Se o que você diz que está errado, pode haver problemas. Um driver inteligente pode detectar como o hardware é realmente definido e rejeitar as informações incorretas fornecidas pela opção (ou pelo menos emitir uma mensagem de erro).

Um requisito óbvio é que, antes que o driver do dispositivo possa usar um endereço, ele deve ser definido primeiro no dispositivo físico (como um cartão). Como os motoristas de dispositivos geralmente começam logo após o início do computador, às vezes tentam acessar um cartão (para ver se está lá, etc.) antes do endereço ser definido no cartão por um programa de configuração do PNP. Então você vê uma mensagem de erro de que eles não conseguem encontrar o cartão, mesmo que esteja lá (mas ainda não tem um endereço).

O que foi dito nos últimos parágrafos em relação aos endereços de E/S se aplica com igual força à maioria dos outros recursos de barramento: intervalos de memória, IRQs-Overview e canais DMA. O que estes são será explicado nas próximas 3 seções. A exceção é que as interrupções no barramento PCI não são definidas por registros de cartões, mas são roteadas (mapeadas) para IRQs por um chip na placa -mãe. Em seguida, a placa IRQ A PCI é roteada é escrita no registro do cartão apenas para fins de informação.

Para ver o que os endereços de IO são usados ​​no seu PC, consulte o arquivo /proc /ioports.

Muitos dispositivos recebem espaço de endereço atribuído na memória principal. Às vezes é chamado de “memória compartilhada” ou “IO mapeada pela memória” ou “Memória de IO”. Essa memória está fisicamente localizada dentro do dispositivo físico, mas o computador o acessa como acessaria a memória nos chips de memória. Ao discutir os recursos de ônibus, muitas vezes é chamado de “Memória”, “Mem” ou “Iomem”. Além de usar essa “memória”, esse dispositivo também pode usar o espaço de endereço IO convencional. Para ver o que o MEM está em uso no seu computador, consulte /proc /iomem. Este “arquivo” inclui a memória usada pelos seus chips de memória de RAM comuns, para que mostre a alocação de memória em geral e não apenas a alocação do IOMEM. Se você vir um número estranho em vez de um nome, é provável que seja o número de um dispositivo PCI que você pode verificar digitando “lspci”.

Quando você insere um cartão que usa o IOMEM, você também está inserindo um módulo de memória para a memória principal. Um endereço alto é selecionado para ele pelo PNP para que não entre em conflito com os principais módulos de memória (chips). Esta memória pode ser ROM (somente leitura de memória) ou memória compartilhada. A memória compartilhada é compartilhada entre o dispositivo e a CPU (executando o driver do dispositivo), assim como o espaço de endereço IO é compartilhado entre o dispositivo e a CPU. Esta memória compartilhada serve como um meio de “transferência” de dados entre o dispositivo e a memória principal. É insput-output (io), mas não é feito no espaço de IO. Tanto o cartão quanto o driver do dispositivo precisam conhecer o intervalo de memória.

ROM (LEIT SOM. É provavelmente um programa (talvez um driver de dispositivo) que será usado com o dispositivo. Pode ser o código de inicialização para que um driver de dispositivo ainda seja necessário. Felizmente, ele funcionará com o Linux e não apenas a MS Windows. Pode precisar ser sombreado, o que significa que é copiado para seus principais chips de memória para correr mais rápido. Uma vez sombreado, não é mais “leitura apenas”.

Depois de ler isso, você pode querer ler interrupções -Details para muito mais detalhes. A seguir, é intencionalmente simplificado: Além do endereço, também há um número de interrupção para lidar (como o IRQ 5). É chamado de número de IRQ (solicitação de interrupção) ou apenas um “IRQ” para abreviar. Já mencionamos acima que o driver do dispositivo deve conhecer o endereço de um cartão para poder se comunicar com ele.

Mas e a comunicação na direção oposta? Suponha que o dispositivo precise dizer ao driver do dispositivo algo imediatamente. Por exemplo, o dispositivo pode estar recebendo muitos bytes destinados à memória principal e seu buffer usado para armazenar esses bytes está quase cheio. Assim, o dispositivo precisa dizer ao seu motorista para buscar esses bytes de uma vez antes que o buffer transborde do fluxo de bytes de entrada. Outro exemplo é sinalizar o motorista que o dispositivo terminou de enviar um monte de bytes e agora está esperando por mais alguns bytes do motorista para que ele possa enviá -los também.

Como o dispositivo deve sinalizar rapidamente seu driver? Pode não ser capaz de usar o barramento de dados principal, pois provavelmente já está em uso. Em vez disso, ele coloca uma tensão em um fio de interrupção dedicado (também chamado de linha ou rastreamento) que geralmente é reservado para esse dispositivo. Este sinal de tensão é chamado de solicitação de interrupção (IRQ) ou apenas uma “interrupção” para abreviar. Há o equivalente a 16 (ou 24, etc.) esses fios em um PC e cada fio de fio (indiretamente) para um determinado driver de dispositivo. Cada fio possui um número exclusivo de IRQ (solicitação de interrupção). O dispositivo deve colocar sua interrupção no fio correto e o driver do dispositivo deve ouvir a interrupção no fio correto. Qual fio o dispositivo envia tais “solicitações de ajuda” é determinado pelo número IRQ armazenado no dispositivo. Esse mesmo número de IRQ deve ser conhecido pelo driver do dispositivo para que o driver do dispositivo saiba em qual linha IRQ.

Depois que o driver do dispositivo recebe a interrupção do dispositivo, ele deve descobrir por que a interrupção foi emitida e tomar as medidas apropriadas para atender a interrupção. No barramento ISA, cada dispositivo geralmente precisa de seu próprio número IRQ exclusivo. Para o barramento PCI e outros casos especiais, o compartilhamento de IRQs é permitido (dois ou mais dispositivos PCI podem ter o mesmo número de IRQ). Além disso, para PCI, cada dispositivo PCI possui um fio fixo de “interrupção PCI”. Mas um chip de roteamento programável mapeia os fios da PCI para interrupções do tipo ISA. Veja interrupções -Details para obter detalhes sobre como tudo o que é acima funciona.

  1. Lendo um pedaço de bytes do espaço de memória de E/S do dispositivo e colocando esses bytes na própria CPU
  2. Escrevendo esses bytes da CPU para a memória principal

Com DMA, é um processo de uma etapa de enviar os bytes diretamente do dispositivo para a memória. O dispositivo deve ter recursos de DMA embutidos em seu hardware e, portanto, nem todos os dispositivos podem fazer DMA. Enquanto o DMA está acontecendo, a CPU não pode fazer muito, já que o ônibus principal está sendo usado pela transferência de DMA.

O antigo ônibus Isa pode fazer DMA lento enquanto o barramento PCI faz “DMA” por masters de ônibus. O barramento LPC possui o antigo DMA e o novo DMA (masterização de ônibus). No barramento PCI, o que mais precisamente deve ser chamado de “masterização de ônibus” é frequentemente chamado de “Ultra DMA”, “BM-DNA”, “UDMA” ou apenas “DMA”, o Mastering de ônibus permite que os dispositivos se tornem temporariamente mestres de ônibus e transfiram bytes quase como o mestre de ônibus era o CPU. Ele não usa números de canal, pois a organização do barramento PCI é tal que o hardware do PCI sabe qual dispositivo é atualmente o mestre de barramento e qual dispositivo está solicitando para se tornar um mestre de ônibus. Portanto, não há alocação de recursos dos canais DMA para o barramento PCI e não existem recursos de canal DMA para este barramento. O barramento LPC (baixo contagem de pinos) deve ser configurado pelo BIOS, para que os usuários não precisem se preocupar com seus canais DMA.

Isso é apenas para o barramento LPC e o velho ônibus ISA. Quando um dispositivo deseja fazer DMA, emite uma solicitação de DMA usando fios de solicitação DMA dedicados, como uma solicitação de interrupção. O DMA realmente poderia ter sido tratado usando interrupções, mas isso introduziria alguns atrasos, por isso é mais rápido fazê-lo com um tipo especial de interrupção conhecida como uma solicitação de DMA. Como interrupções, as solicitações de DMA são numeradas para identificar qual dispositivo está fazendo a solicitação. Este número é chamado de canal DMA. Como os transferências de DMA usam o barramento principal (e apenas um pode ser executado por vez), todos eles realmente usam o mesmo canal para fluxo de dados, mas o número “DMA Channel” serve para identificar quem está usando o “canal”. Os registros de hardware existem na placa -mãe que armazenam o status atual de cada “canal”. Assim, para emitir uma solicitação de DMA, o dispositivo deve conhecer seu número de canal DMA, que deve ser armazenado em um registro especial no dispositivo físico.

Assim, os drivers de dispositivo devem ser “anexados” de alguma forma ao hardware que controlam. Isso é feito alocando recursos de barramento (E/S, memória, IRQs, DMAs) para o dispositivo físico e deixando o driver do dispositivo descobrir sobre isso. Por exemplo, uma porta serial usa apenas 2 recursos: um IRQ e um endereço de E/S. Ambos os valores devem ser fornecidos ao driver do dispositivo e ao dispositivo físico. O driver (e seu dispositivo) também recebe um nome no diretório /dev (como TTYS1). O endereço e o número IRQ são armazenados pelo dispositivo físico nos registros de configuração em seu cartão (ou em um chip na placa -mãe). O hardware antigo (em meados dos anos 90) usou interruptores (ou jumpers) para definir fisicamente o IRQ e o endereço no hardware. Essa configuração permaneceu fixa até que alguém remova a capa do computador e mova os jumpers.

Mas, para o caso do PNP (sem jumpers), os dados do registro de configuração geralmente são perdidos quando o PC é desligado (desligado) para que os dados da recursos do barramento sejam fornecidos a cada dispositivo de novo cada vez que o PC é alimentado.

Computadores ideais

A arquitetura do PC fornece apenas um número limitado de recursos: IRQs, canais DMA, endereço de E/S e regiões de memória. Se houvesse apenas dispositivos de números limitados e todos usassem valores padronizados de resistência ao barramento (como endereços de E/S exclusivos e números de IRQ), não haveria problema de conectar drivers de dispositivo a dispositivos. Cada dispositivo teria recursos fixos que não entrariam em conflito com nenhum outro dispositivo no seu computador. Não teriam dois dispositivos os mesmos endereços, não haveria conflitos de IRQ no ônibus ISA, etc. Cada motorista seria programado com os endereços exclusivos, IRQ, etc. codificado no programa. A vida seria simples.

Outra maneira de evitar o tratamento de conflitos seria ter o número do slot de cada cartão incluído como parte do endereço. Assim, não poderia haver endereço de conflito entre dois cartões diferentes (pois eles estão em slots diferentes). O design do cartão não permitiria abordar conflitos entre diferentes funções do cartão. Acontece que o espaço de endereço de configuração (usado para consulta de recursos e atribuição) realmente faz isso. Mas isso não é feito para endereços de E/S nem regiões de memória. Compartilhar IRQs como no barramento PCI também evita conflitos, mas pode causar outros problemas.

Computadores reais

Mas a arquitetura do PC tem problemas de conflito. O aumento do número de dispositivos (incluindo vários dispositivos do mesmo tipo) tendeu a aumentar os conflitos em potencial. Ao mesmo tempo, a introdução do barramento PCI, onde dois ou mais dispositivos podem compartilhar a mesma interrupção e a introdução de mais interrupções, tendem a reduzir os conflitos. O resultado geral, devido a ir para PCI, tem sido uma redução nos conflitos, pois o recurso mais escasso é IRQS. No entanto, mesmo no barramento PCI, é mais eficiente evitar o compartilhamento de IRQ. Em alguns casos em que as interrupções ocorrem em rápida sucessão e devem ser agidas no compartilhamento rápido (como o áudio) podem causar degradação no desempenho. Portanto, não é bom atribuir a todos os dispositivos PCI o mesmo IRQ, a tarefa precisa ser equilibrada. No entanto, algumas pessoas acham que todos os seus dispositivos PCI estão no mesmo IRQ.

Portanto, os dispositivos precisam ter alguma flexibilidade para que possam ser definidos para qualquer endereço, IRQ, etc. é necessário para evitar conflitos e alcançar o equilíbrio. Mas alguns IRQs e endereços são bastante padrão, como os do relógio e do teclado. Estes não precisam de tanta flexibilidade.

Além do problema de alocação conflitante de recursos de barramento, há um problema de cometer um erro ao dizer ao driver do dispositivo o que as resmunções de ônibus são. É mais provável que isso aconteça para o caso de configuração manual antiquada, onde o usuário digita os recursos usados ​​em um arquivo de configuração armazenado no harddrive. Isso muitas vezes funcionou bem quando os recursos eram definidos por jumpers nos cartões (desde que o usuário soubesse como eles foram definidos e não cometeram erros em digitar esses dados para arquivos de configuração). Mas com os recursos estabelecidos pelo software PNP, eles nem sempre são definidos da mesma forma e isso pode significar problemas para qualquer configuração manual em que o usuário digita os valores de recursos de barramento que foram definidos pelo PNP.

A alocação de recursos de barramento, se feita corretamente, estabelece canais de comunicação não conflitantes entre hardware físico e seus drivers de dispositivo. Por exemplo, se um certo intervalo de endereços de E/S (recurso) for alocado para um driver de dispositivo e um hardware, isso estabeleceu um canal de comunicação unidirecional entre eles. O motorista pode enviar comandos e outras informações para o dispositivo. Na verdade, é mais do que comunicações unidirecionais, já que o motorista pode obter informações do dispositivo lendo seus registros. Mas o dispositivo não pode iniciar nenhuma comunicação dessa maneira. Para iniciar a comunicação, o dispositivo precisa de um IRQ para que possa enviar interrupções ao seu driver. Isso cria um canal de comunicação de mão dupla, onde o driver e o dispositivo físico podem iniciar a comunicação.

O termo plug-and-play (PNP) tem vários significados. No sentido amplo, é apenas uma configuração automática, onde apenas se conecta a um dispositivo e se configura. No sentido usado neste Howto, PNP significa a configuração de recursos de barramento PNP (definindo-os nos dispositivos físicos) e informação dos drivers do dispositivo. Para o caso do Linux, geralmente é apenas um motorista que determina como o BIOS definiu recursos de barramento e, se necessário. “PNP” geralmente significa apenas PNP no barramento ISA, para que a mensagem do ISAPNP: “Nenhum dispositivo plug and play encontrado” significa apenas que não foram encontrados dispositivos ISA PNP. As especificações padrão do PCI (que foram inventadas antes de cunhar o termo “PNP”) fornecem o equivalente ao PNP para o barramento PCI.

O PNP corresponde aos dispositivos com seus drivers de dispositivo e especifica seus canais de comunicação (alocando recursos de barramento). Ele se comunica eletronicamente com registros de configuração localizados dentro dos dispositivos físicos usando um protocolo padronizado. No ônibus da ISA antes do plug-and-play, os recursos de ônibus eram anteriormente definidos em dispositivos de hardware por jumpers ou interruptores. Às vezes, os recursos de ônibus podem ser colocados no hardware eletronicamente por um driver (geralmente escrito apenas para um MS OS, mas em casos raros suportados por um driver Linux). Isso era algo como PNP, mas não havia um protocolo padronizado usado, então não foi realmente PNP. Alguns cartões tinham configuração de jumper que poderia ser substituída por esse software. Para o Linux antes do PNP, a maioria dos drivers de software recebeu recursos de barramento por arquivos de configuração (ou similares) ou sondando o dispositivo para o dispositivo em endereços onde se espera que fosse residir. Mas esses métodos ainda estão em uso hoje para permitir que o Linux use hardware antigo não pnp. E às vezes esses métodos antigos ainda são usados ​​hoje em hardware PNP (depois de dizer que o BIOS atribuiu recursos ao hardware pelos métodos PNP).

O barramento PCI era parecido com PNP desde o início, mas geralmente não é chamado de PNP ou “Plug and Play” com o resultado de que o PNP geralmente significa PNP no barramento ISA. Mas o PNP nesses documentos geralmente significa PNP no barramento ISA ou PCI.

Aqui está como o PNP deve funcionar em teoria. O hipotético Programa de Configuração PNP encontra todos os dispositivos PNP e pergunta a cada um de que recursos de ônibus precisa. Então ele verifica quais recursos de ônibus (IRQs, etc.) tem que doar. Obviamente, se tiver recursos de barramento reservados usados ​​por dispositivos não-pnp (Legacy) (se os conhecerem), não os distribui. Em seguida, ele usa alguns critérios (não especificados pelas especificações do PNP) para distribuir os recursos de ônibus para que não haja conflitos e para que todos os dispositivos obtenham o que precisam (se possível). Em seguida, indiretamente diz a cada dispositivo físico quais recursos de barramento são atribuídos a ele e os dispositivos se preparam para usar apenas os recursos de barramento atribuídos. Em seguida, os drivers de dispositivo descobrem de alguma forma quais recursos de barramento seus dispositivos usam e, portanto, são capazes de se comunicar efetivamente com os dispositivos que eles controlam.

Por exemplo, suponha que um cartão precise de uma interrupção (número IRQ) e 1 MB de memória compartilhada. O programa PNP lê esta solicitação dos registros de configuração no cartão. Em seguida, atribui o cartão IRQ5 e 1 MB do espaço de endereços de memória, começando no endereço 0xe9000000. O programa PNP também lê informações de identificação do cartão, dizendo que tipo de dispositivo é, seu número de identificação, etc. Então ele diz direta ou indiretamente ao driver de dispositivo apropriado o que é feito. Se é o driver em si que está fazendo o PNP, não há necessidade de encontrar um driver para o dispositivo (já que o driver já está em execução). Caso contrário, um driver de dispositivo adequado precisa ser encontrado e mais cedo ou mais tarde informado como o dispositivo está configurado.

Nem sempre é tão simples, pois o cartão (ou tabela de roteamento para PCI) pode especificar que ele só pode usar certos números de IRQ ou que o 1 MB de memória deve estar dentro de uma certa gama de endereços. Os detalhes são diferentes para os ônibus PCI e ISA com mais complexidade no barramento ISA.

Uma maneira comumente usada para alocar recursos é começar com um dispositivo e alocar-se de barramento de barramento. Então faça o mesmo para o próximo dispositivo, etc. Então, se finalmente todos os dispositivos receberem recursos alocados sem conflitos, tudo está ok. Mas se a alocação de um recurso necessário criaria um conflito, é necessário voltar e tentar fazer algumas alterações nas alocações anteriores, a fim de obter o barramento de barro necessário. Isso é chamado de reequilíbrio. Linux não faz reequilíbrio, mas o Windows faz em alguns casos. Para Linux, tudo isso é feito pelo BIOS e/ou kernel e/ou drivers de dispositivo. No Linux, o driver do dispositivo não obtém a alocação final de recursos até o início do motorista, portanto, uma maneira de evitar conflitos é apenas para iniciar nenhum dispositivo que possa causar um conflito. No entanto, o BIOS geralmente aloca recursos para o dispositivo físico antes mesmo de Linux ser inicializado e o kernel verifica os dispositivos PCI para endereços conflitos na hora da inicialização.

Existem alguns atalhos que o software PNP pode usar. Uma é acompanhar como atribuiu recursos de barramento na última configuração (quando o computador foi usado pela última vez) e reutilize isso. BioSs faz isso como o MS Windows e isso, mas o Linux padrão não. Mas de certa forma faz, pois muitas vezes usa o que o BIOS fez. O Windows armazena essas informações em seu “Registro” no disco rígido e um PNP/PCI BIOS o armazena em memória não volátil no seu PC (conhecida como ESCD; consulte o banco de dados Escd do BIOS). Alguns dizem que não ter um registro (como o Linux) é melhor, pois com o Windows, o registro pode ser corrompido e é difícil de editar. Mas o PNP no Linux também tem problemas.

Enquanto MS Windows (exceto para Windows 3.x e nt4) foram PNP, o Linux não era originalmente um PNP OS, mas está gradualmente se tornando um PNP OS. O PNP trabalhou originalmente para o Linux porque um PNP BIOS configuraria os recursos de ônibus e os drivers de dispositivo descobririam (usando programas fornecidos pelo kernel Linux) o que o BIOS fez. Hoje, a maioria dos motoristas pode emitir comandos para fazer seu próprio recurso de barro de barramento e não precisa sempre confiar no BIOS. Infelizmente, um motorista pode pegar um recurso de ônibus que outro dispositivo precisará mais tarde. Alguns drivers de dispositivo podem armazenar a última configuração que usaram em um arquivo de configuração e usá -lo na próxima vez que o computador for ligado.

Se o hardware do dispositivo lembras. Mas o hardware parece esquecer sua configuração quando a energia é desligada. Alguns dispositivos contêm uma configuração padrão (mas não necessariamente o último usado). Assim, um dispositivo PNP precisa ser reconfigurado cada vez que o PC é alimentado. Além disso, se um novo dispositivo foi adicionado, ele também precisa ser configurado também. A alocação de recursos de ônibus para este novo dispositivo pode envolver tirar alguns recursos de barramento de um dispositivo existente e atribuir o dispositivo existente de resistência ao barramento que ele pode usar em vez disso. Atualmente, o Linux não pode alocar com essa sofisticação (e o MS Windows XP também pode não ser capaz de fazê -lo).

Quando o PC é ativado pela primeira vez no chip do BIOS, executa seu programa para iniciar o computador (a primeira etapa é verificar o hardware da placa -mãe). Se o sistema operacional for armazenado no drago (como normalmente é), o BIOS deve saber sobre o tração rígida. Se a dura draiva for PNP, o BIOS poderá usar métodos PNP para encontrá-lo. Além disso, para permitir que o usuário configure manualmente os CMOs do BIOS e responda a mensagens de erro quando o computador iniciar, uma tela (placa de vídeo) e teclado também são necessários. Assim, o BIOS deve sempre os dispositivos de configuração de PNP necessários para carregar o sistema operacional a partir do tração rígida.

Depois que o BIOS identificar a drageira, a placa de vídeo e o teclado, ela está pronta para começar a inicializar (carregando o sistema operacional na memória do disco rígido). Se você disse ao BIOS que tem um sistema operacional PNP (PNP OS), ele deve começar a inicializar o PC como acima e deixar o sistema operacional terminar o PNP Configurando. Caso contrário, um PNP-BIOS (antes da inicialização) provavelmente tentará fazer o restante do PNP configurando os dispositivos (mas não informará os drivers de dispositivo sobre o que ele fez). Mas os motoristas ainda podem descobrir isso utilizando funções disponíveis no kernel Linux.

Para ver o que está no tipo de barramento PCI LSPCI ou LSPCI -VV . Ou digite scanpci -v para obter as mesmas informações no formato de código numérico em que o dispositivo é mostrado por número (como: “dispositivo 0x122d” em vez de nome, etc. Em casos raros, o scanpci encontrará um dispositivo que o LSPCI não consegue encontrar.

As mensagens de tempo de inicialização em seus dispositivos de exibição exibidos que foram encontrados em vários ônibus (use Shift-PageUp para fazer backup através deles). Veja mensagens de tempo de inicialização

Isa é o ônibus antigo dos antigos PCs compatíveis com IBM, enquanto o PCI é um ônibus mais novo e mais rápido da Intel. O barramento PCI foi projetado para o que hoje é chamado PNP. Isso facilita (em comparação com o barramento ISA) descobrir como os recursos de barramento do PNP foram atribuídos a dispositivos de hardware.

Para o barramento ISA, houve um problema real na implementação do PNP, pois ninguém tinha em mente o PNP quando o barramento do ISA foi projetado e quase não há endereços de E/S disponíveis para o PNP usar para enviar informações de configuração para um dispositivo físico. Como resultado, a maneira como o PNP foi calçado no ônibus Isa é muito complicado. Livros inteiros foram escritos sobre isso. Veja o PNP Book. Entre outras coisas, exige que cada dispositivo PNP seja atribuído a um “identificador” temporário pelo programa PNP para que se possa abordá -lo para o PNP configurando. Atribuir essas “alças” é uma chamada “isolamento”. Veja o isolamento de Isa para os detalhes complexos.

À medida que o barramento do ISA se extinguir, o PNP será um pouco mais fácil. Não será apenas mais fácil descobrir como o BIOS configurou o hardware, mas haverá menos conflitos, pois o PCI pode compartilhar interrupções. Ainda haverá a necessidade de combinar drivers de dispositivo com dispositivos e também uma necessidade de configurar dispositivos adicionados quando o PC está em funcionamento e em execução. O problema sério de alguns dispositivos não serem suportados pelo Linux permanecerá.

O Linux teve problemas sérios no passado ao lidar com o PNP, mas a maioria desses problemas já foi resolvida (em meados de 2004). Linux passou de um sistema não pnp originalmente, para um que pode ser PNP se certas opções forem selecionadas ao compilar o kernel. O BIOS pode atribuir IRQs, mas o Linux também pode atribuir alguns deles ou até reatribuir o que o BIOS fez. A parte de configuração do ACPI (interface de configuração e energia avançada) foi projetada para facilitar para os sistemas operacionais fazer sua própria configuração. Linux pode usar ACPI se for selecionado quando o kernel for compilado.

No Linux, é tradicional para cada driver de dispositivo fazer seu próprio nível de configuração. Isso foi difícil até que o Linux forneça o software no kernel que os motoristas pudessem usar para facilitar. Hoje (2005) chegou ao ponto em que o motorista simplesmente chama a função do kernel: pci_enable_device () e o dispositivo é configurado por ser ativado e ter um IRQ (se necessário) e endereços atribuídos ao dispositivo. Esta tarefa pode ser o que foi atribuído anteriormente pelo BIOS ou o que o kernel havia reservado anteriormente quando o dispositivo PCI ou ISAPNP foi detectado pelo kernel. Existe até uma opção ACPI para o Linux atribuir todos os dispositivos IRQs na hora da inicialização.

Então, hoje, em certo sentido, os motoristas ainda estão configurando, mas podem fazê -lo apenas dizendo ao Linux para fazê -lo (e o Linux pode não precisar fazer muito, pois às vezes é capaz de usar o que já foi definido pelo BIOS ou Linux). Portanto, é realmente a parte não-device-motor do kernel Linux que está fazendo a maior parte da configuração. Assim, pode ser correto chamar Linux de sistema operacional PNP, pelo menos para arquiteturas de computadores comuns.

Então, quando um driver de dispositivo encontra seu dispositivo, ele pede para ver quais endereços e IRQ foram atribuídos (pelo BIOS e/ou Linux) e normalmente apenas os aceita. Mas se o motorista quiser fazer isso, pode tentar alterar os endereços, usando funções fornecidas pelo kernel. Mas o kernel não aceitará endereços que conflitam com outros dispositivos ou aqueles que o hardware não pode suportar. Quando o PC inicia, você pode observar mensagens na tela mostrando que alguns drivers de dispositivo Linux encontraram seus dispositivos de hardware e o que são o IRQ e as faixas de endereço.

Assim, o kernel fornece aos motoristas funções (código do programa) que os motoristas podem usar para descobrir se o dispositivo existe, como ele foi configurado e funções para modificar a configuração, se necessário. Kernel 2.2 poderia fazer isso apenas para o barramento PCI, mas o kernel 2.4 tinha esse recurso para os ônibus ISA e PCI (desde que as opções apropriadas de PNP e PCI tenham sido selecionadas ao compilar o kernel). Kernel 2.6 saiu com melhor utilização do ACPI. Isso não garante que todos os motoristas usem total e corretamente esses recursos. E os dispositivos legados que o BIOS não conhecem podem não ser configurados até que você (ou algum utilitário de configuração) coloque seu endereço, IRQ, etc. em um arquivo de configuração.

Além disso, o kernel ajuda a evitar conflitos de recursos, por não permitir dois dispositivos que sabe usar os mesmos recursos de barramento ao mesmo tempo. Originalmente, isso era apenas para IRQs e DMAs, mas agora é para recursos de endereço também.

Se você tem um ônibus antigo do ISA, o programa ISAPNP deve ser executado no Boottime para encontrar e configurar dispositivos PNP no barramento ISA. Veja as mensagens com “DMESG”.

Para ver qual ajuda o kernel pode fornecer aos drivers de dispositivo, consulte o diretório /usr /. /. /Documentação onde um dos . contém a palavra “kernel-doc” ou similar. Aviso: A documentação aqui tende a estar desatualizada para obter as informações mais recentes que você precisa para ler mensagens em listas de discussão enviadas pelos desenvolvedores do kernel e possivelmente o código do computador que eles escrevem, incluindo comentários. Neste diretório de documentação do kernel, ver PCI.txt (“Como escrever drivers PCI Linux”) e o arquivo:/usr/incluir/linux/pci.h. A menos que você seja um guru do driver e conheça a programação C, esses arquivos são escritos de forma tão elegante que eles não permitirão que você escreva um driver. Mas isso lhe dará uma idéia do que as funções do tipo PNP estão disponíveis para os motoristas usarem.

Para o kernel 2.4 Veja ISAPNP.TXT. Para o kernel 2.6, isapnp.txt é substituído por pnp.txt que é totalmente diferente do ISAPNP.txt e também lida com o barramento PCI. Veja também The O’Reilly Book: Linux Disposition Drivers, 3rd Ed., 2005. O texto completo está na internet.

Mas há várias coisas que um sistema operacional PNP real poderia suportar melhor:

  • Alocar recursos de ônibus quando estiverem em falta pela realocação de recursos, se necessário
  • Lidar com a escolha de um motorista quando há mais de um driver para um dispositivo físico

Como é cada motorista para si, um motorista pode pegar recursos de ônibus que são necessários para outros dispositivos (mas ainda não alocados para eles pelo kernel). Assim, um kernel PNP Linux mais sofisticado seria melhor, onde o kernel fez a alocação depois que todos os pedidos estavam em. Outra alternativa seria uma tentativa de realocar recursos já atribuídos se um dispositivos não pudessem obter os recursos solicitados.

O problema da “escassez de resmungos de barramento” está se tornando menos um problema por dois motivos: um motivo é que o barramento PCI está substituindo o barramento ISA. Sob PCI, não há escassez de IRQs, pois os IRQs podem ser compartilhados (mesmo que o compartilhamento seja um pouco menos eficiente). Além disso, o PCI não usa recursos de DMA (embora faça o equivalente ao DMA sem precisar desses recursos).

A segunda razão é que mais espaço de endereço está disponível para o dispositivo I/0. Enquanto o espaço de endereço de E/S convencional do barramento ISA foi limitado a 64kb, o barramento PCI tem 4 GB. Como mais dispositivos físicos estão usando os principais endereços de memória em vez do espaço de endereço de IO, ainda há mais espaço disponível, mesmo no barramento ISA. Nos PCs de 32 bits, há 4 GB do espaço de endereço de memória principal e grande parte deste RESOURCE DE BUS está disponível para o dispositivo IO (a menos que você tenha 4 GB de memória principal instalada).

Informações gerais sobre suporte para dispositivos de plug & play

Os dispositivos plug & play podem ser usados ​​imediatamente, sem a necessidade de instalação. Estes são detectados e configurados automaticamente assim que estão conectados a um computador. Os drivers de dispositivo apropriados são instalados automaticamente. O usuário não é necessário para fazer nenhuma entrada.

A instalação automática pelo sistema operacional funciona apenas, no entanto, sob certas condições, e.g. (Veja mais sobre isso no Windows Help):

  • O driver do dispositivo tem o “Desenvolvido para Windows” logotipo ou assinatura digital.
  • O driver do dispositivo já está presente no computador.

Se essas condições não forem atendidas, o sistema operacional lança o assistente de hardware. Se o usuário não tiver direitos de administrador local, ele não poderá concluir a instalação com este assistente.

Nessas situações, DSM ’S Suporte para dispositivos Plug & Play Permite que os dispositivos sejam instalados sem que o usuário tenha direitos de administrador local.

  • Wan Miniport Drivers
  • Adaptadores de rede virtual

Este artigo foi útil?

Forçar o dispositivo plug-n-play para usar determinado driver

Equipamento: Microfone de Revelador Presonus O objetivo: Gostaria de usar meu microfone mais longe por meio de uma extensão USB para RJ45. Basicamente enviando USB sobre um cabo Ethernet. O problema: Quando o microfone está conectado diretamente ao laptop, ele funciona bem. Mas quando eu o conecto sobre o extensor, não posso gravar nada e o computador não registra o dispositivo. O microfone está recebendo energia e o computador faz o ruído de “conexão”, mas nada além disso. Gerenciador de Dispositivos: Eu verifiquei o gerenciador de dispositivos em ambos os cenários. Quando conectado diretamente, vejo “Microfone (Revelador)” em “entradas e saídas de áudio”. Quando conectado sobre o RJ45, eu apenas vejo “Revelador” em “Dispositivos desconhecidos”, bem como o triângulo de aviso amarelo indicando que nenhum motorista foi carregado. Informações do driver: Eu usei o programa USBDeView para coletar algumas informações detalhadas no dispositivo quando conectado usando as diferentes conexões. Abaixo está uma comparação lado a lado.

Conectado diretamente Conectado via RJ45
Nome do dispositivo Revelador Revelador
Descrição Dispositivo composto USB Revelador
Tipo de dispositivo Desconhecido Específico do fornecedor
Conectado Sim Sim
Seguro para desconectar Sim Não
Desabilitado Não Não
Hub USB Não Não
Número de série JM1C20431589 JM1C20431589
VENDORID 194f 194f
ID do produto 0d01 0d01
Revisão de firmware 1.02 1.02
Classe USB 0 ff
Subclasse USB 0 0
Protocolo USB 0 0
Prefixo Parentid 6 & 1ea95f5f e 0 6 & 1ea95f5f e 0
Nome do Serviço USBCCGP
Descrição do Serviço @USB.inf,%genérico.SVCDESC%; Microsoft USB Generic Parent Driver
Nome do arquivo do motorista USBCCGP.sys
Dispositivo mfg (Controlador Host Standard USB)
Poder 200 MA 200 MA
Versão USB 2 2
Descrição do driver Dispositivo composto USB
Versão do driver 10.0.19041.1949
Infseção do motorista Composto.Dev.Nt
Driver infpath USB.inf
ID da instância USB \ VID_194F & PID_0D01 \ JM1C20431589 USB \ VID_194F & PID_0D01 \ JM1C20431589
Recursos “Removável, exclusivo, SurpremeMovalok” “Removável, exclusivo”

A principal diferença é que, quando conectado diretamente, o microfone é reconhecido como um dispositivo composto (USBDeView também mostra vários outros dispositivos USB sendo carregados ao mesmo tempo). Quando conectado ao RJ45, não é reconhecido como tal e sem cargas de motorista. Outros dispositivos podem conectar?: Eu tentei o conector RJ45 com uma unidade USB e uma marca diferente de microfone (Audio-Technica At2020). Nos dois casos, eles funcionaram bem e carregaram os mesmos motoristas. O microfone é especialmente interessante, pois também é um dispositivo composto, mas não tem problemas. Pergunta: É possível forçar meu computador a usar o mesmo driver nos dois cenários? Eu tenho feito um pouco de Google, mas tudo o que posso encontrar são coisas relacionadas ao download de drivers do site da empresa (não há nenhum que eu possa encontrar). Eu tentei selecionar manualmente os arquivos SYS e INF através do gerenciador de dispositivos, mas isso não parecia funcionar. Possível, estou fazendo esta etapa errada embora.

O que é um driver de dispositivo? Definição, tipos e aplicações

Um driver de dispositivo é um programa sem uma interface do usuário que gerencia o hardware conectado a um computador e suporta seu funcionamento.

Chiradeep Basumallick Writer Technical

12 de outubro de 2022

Um engenheiro de sistemas reiniciando um driver de dispositivo por meio de um iPad

Um driver de dispositivo é definido como um programa de software sem uma interface de usuário (UI) que gerencia componentes de hardware ou periféricos conectados a um computador e permite que eles funcionem com o computador sem problemas. Este artigo explica o funcionamento dos drivers de dispositivos, seus vários tipos e cinco aplicações críticas.

Índice

    • O que é um driver de dispositivo?
    • 9 tipos de drivers de dispositivo
    • Aplicações de drivers de dispositivo

    O que é um driver de dispositivo?

    Um driver de dispositivo é um programa de software sem uma interface de usuário (UI) que gerencia componentes de hardware ou periféricos conectados a um computador e permite que eles funcionem com o computador sem problemas.

    Um driver de dispositivo é um software especializado que opera um dispositivo específico conectado ao computador-oferecendo uma interface de software para o hardware permite que sistemas operacionais e outros aplicativos de computador acessem funcionalidades de hardware.

    O hardware está vinculado a um subsistema de barramento/comunicação por computador através do qual os drivers de dispositivo interagem com o dispositivo. Eles são dependentes de hardware e específicos do sistema operacional (OS). Eles oferecem o processamento de interrupção essencial para qualquer interface de hardware assíncrona dependente do tempo.

    Um driver de dispositivo’s O objetivo principal é permitir que computadores e componentes de hardware de rede interface e interajam com dispositivos específicos. Eles lidam com os pedidos feitos pelo kernel sobre um tipo específico de dispositivo. Os drivers de dispositivo definem mensagens e mecanismos pelos quais o computador’S Sistema Operacional e Aplicativos podem acessar o dispositivo ou fazer solicitações para o dispositivo. Eles também lidam com as respostas e mensagens do dispositivo para entrega ao computador.

    Como os drivers de dispositivo funcionam

    Os drivers de dispositivo operam dentro da camada do kernel do sistema operacional. Eles trabalham em um ambiente altamente privilegiado porque precisam de acesso de baixo nível a operações de hardware para funcionar. Eles permitem o computador’S Sistema Operacional (OS) para interagir com o hardware para o qual foram desenvolvidos. E através de um barramento de computador que vincula o dispositivo ao computador, os drivers e o dispositivo se comunicam.

    Os drivers de dispositivo devem receber conselhos do sistema operacional para acessar e executar instruções do dispositivo. Depois de concluir o trabalho, eles transmitem o dispositivo de hardware’s Saída ou mensagem para o sistema operacional. Dispositivos como modems, roteadores, alto -falantes, teclados e impressoras exigem que os drivers de dispositivo operem.

    Entendendo o desenvolvimento do driver do dispositivo

    Os drivers de dispositivo permitem que dispositivos periféricos, como impressoras ou teclados, interajam com o computador. Os seguintes descrevem as etapas que desenvolvedores ou programadores podem tomar ao desenvolver drivers de dispositivos para sistemas operacionais, como Windows, Linux ou MacOS.

    1. Conheça o equipamento

    Ao projetar um driver de dispositivo, os programadores devem ter uma compreensão aprofundada da plataforma’s hardware. Eles devem saber a interface do barramento que o hardware usa para se comunicar com o host e a localização do software de driver de dispositivo. Eles devem ler a folha de dados do dispositivo para entender os termos e definições relevantes. Eles também devem saber o método através de qual transferência de dados ocorre.

    Se o dispositivo principal for um sistema no chip, os desenvolvedores devem saber como o motorista interage com seus protocolos de firmware e comando. Além disso, os desenvolvedores devem estar preparados para que a documentação fique aquém ao lidar com um novo tipo de hardware. Assim, eles devem estar prontos para realizar mais testes do que o normal.

    2. Escreva o código do driver

    Nesta etapa, os desenvolvedores devem obter um protótipo funcional de seu hardware preferido. Então eles devem começar a escrever o driver do modo de kernel.

    Se um dispositivo for projetado incorretamente, os drivers que executam no modo de usuário podem causar uma falha no sistema. Da mesma forma, se algo der errado quando os motoristas estão operando em ambientes altamente privilegiados, podem ocorrer preocupações operacionais. Assim, os desenvolvedores devem tirar proveito das informações na documentação de desenvolvimento de driver disponível para o sistema operacional selecionado, seja Windows ou Linux.

    As primeiras funções do driver de dispositivo desenvolvidas são as funções de carga e descarga. Quando o sistema operacional é iniciado e para, essas funções são chamadas. Uma das principais responsabilidades das funções de carga/descarga é detectar se o hardware está conectado ao sistema ou não. Os usuários podem detectar hardware usando o ID do dispositivo especificado pelo barramento específico. Se o hardware estiver conectado, a função de carga será bem -sucedida. Caso contrário, chame a função de descarga.

    3. Inicialize o hardware

    Depois que o dispositivo pode detectar o hardware, o próximo passo será inicializando. O tipo de inicialização necessário pode diferir dependendo do tipo de hardware. A inicialização pode variar desde a escrita até o registro do dispositivo até o download de um microcódigo no dispositivo e se comunicando a longo prazo usando protocolos de comando proprietários.

    4. Controle o hardware

    Controlar o hardware só é possível se os desenvolvedores podem inicializar e se comunicar com o hardware. O processo de controle depende do dispositivo. Os desenvolvedores devem considerar se o dispositivo simplesmente transmitirá dados de um dispositivo para outro.

    Por exemplo, ao transmitir música de um smartphone para um alto -falante. Eles também devem considerar se o dispositivo enviará continuamente dados e instruções para outros dispositivos. Por exemplo, dizendo a uma impressora para imprimir preto e branco em um lado de papel, seguido de uma impressão dupla face em cores.

    O driver do dispositivo liga as configurações de dados, como a velocidade de reprodução e a entrada de avanço rápido através do computador em comandos para o dispositivo. Ao contrário das três etapas anteriores, este pode levar mais tempo. As três primeiras etapas podem ser uma operação única à medida que o sistema operacional carrega. No entanto, os desenvolvedores podem precisar executar a Etapa 4 várias vezes após a configuração do sistema operacional. Às vezes, os usuários podem mesclar os 3º e 4º passos em uma única etapa.

    5. Comece a comunicação de dados com o hardware

    Vários dispositivos lidam com alguma forma de dados, seja áudio ou vídeo. Depois que o dispositivo é inicializado, os desenvolvedores podem enviar um fluxo constante de dados, conforme necessário. O driver do dispositivo atua como um tubo entre o aplicativo de nível superior e o hardware ou firmware de nível inferior para transferência de dados.

    Conforme observado na primeira etapa, os desenvolvedores devem conhecer os protocolos projetados para comunicação de dados. As transferências de dados podem ser orientadas por interrupções ou pesquisadas. O sistema operacional fornece instalações como mensagens ou rotinas de serviço de interrupção usadas durante o processo de transferência de dados. Os desenvolvedores devem começar transferindo um único pacote de dados e garantindo que todo o processo das etapas 1 a 3 funcione bem.

    6. Controle a comunicação de dados

    Nesta etapa, os desenvolvedores precisam controlar a transferência de dados e gerenciar a comunicação em várias situações. Quando surgem problemas, os usuários devem impedir que os dispositivos periféricos enviem a mesma mensagem de erro. Em um fluxo de áudio, quando houver um excesso de buffer ou um problema significativo com a qualidade do som, eles devem enviar um comando de parada.

    7. Teste o motorista e depra -o

    O teste é um aspecto crucial. Os desenvolvedores devem testar o dispositivo para garantir que seja reconhecido e inicializado. Eles também devem executar testes funcionais para garantir que os drivers do dispositivo funcionem conforme o esperado. Eles também devem estar prontos para fazer alterações no hardware para garantir uma operação suave. Além disso, os desenvolvedores devem testar os drivers de dispositivo em diferentes versões do sistema operacional para verificar se eles estão para a frente e compatíveis com a frente. Depois que o driver do dispositivo funciona, os desenvolvedores podem registrá -lo.

    9 tipos de drivers de dispositivo

    Os desenvolvedores podem distinguir os seguintes tipos de drivers de dispositivo:

    1. Drivers de dispositivo do kernel

    Os drivers de dispositivo do kernel consistem em algum hardware genérico carregado com o sistema operacional (OS) como parte do sistema operacional. Eles incluem placas -mãe, processadores e BIOS. Eles são invocados e carregados na memória de acesso aleatório (RAM) quando necessário. Quando vários deles estão operando ao mesmo tempo, a máquina pode desacelerar. Assim, existe um requisito mínimo para cada sistema operacional.

    Os drivers de dispositivo do kernel estão em camadas. Drivers de nível superior, como drivers de sistema de arquivos, recebem dados de aplicativos, filtram-os e passam para um driver de nível inferior, suportando funcionalidade de unidade. Os drivers de dispositivos do kernel são implementados como componentes discretos e modulares com um conjunto bem definido de funcionalidades necessárias.

    2. Drivers de dispositivo no modo de usuário

    Drivers de dispositivo de modo de usuário executados no modo de usuário. Eles se referem a drivers de dispositivo que os usuários podem acionar durante uma sessão. Ao usar um sistema, os usuários podem ter seus próprios dispositivos externos que eles trazem para usar, como dispositivos externos plug-and-play. Esses dispositivos também exigem que os motoristas funcionem. Nos sistemas Windows, os drivers de dispositivo de modo de usuário fornecem uma interface entre um aplicativo Win32 e drivers de modo de kernel ou outros sistemas operacionais. Os usuários podem escrever esses drivers no disco para reduzir a tensão nos recursos do computador.

    3. Drivers de personagem

    Os drivers de dispositivo de caracteres fornecem acesso não estruturado ao hardware. Eles transferem dados para e para dispositivos sem usar um endereço de dispositivo específico. Eles permitem a leitura ou a escrita de um byte de cada vez como um fluxo de dados seqüenciais. Os drivers de caracteres não lidam. Eles estão emparelhados com dispositivos de bloco para contornar o cache do buffer para oferecer operações de E/S em RAW para o espaço de endereço do programa do usuário.

    Além disso, eles fornecem interfaces adicionais, como comandos de controle de E/S, pesquisa de dispositivos e mapeamento de memória. Exemplos são modems e controladores de barramento.

    4. Drivers de bloqueio

    Os drivers de dispositivo de bloco fornecem acesso estruturado ao hardware. Eles usam buffers de tamanho de bloco do sistema de arquivos de um cache de buffer fornecido pelo kernel para executar a E/S. Um cache de buffer é um pool de memória estabelecido pelo kernel para armazenar blocos frequentemente acessados ​​por meio de dispositivos de bloco. O cache do buffer reduz a quantidade de consultas de E/S que precisam de uma operação de E/S do dispositivo.

    Além disso, os drivers de dispositivo de bloco fornecem E/S acessível orientada a blocos e demonstram durabilidade de dados. Eles recebem uma solicitação do sistema de arquivos e emitem os procedimentos de E/S para o disco para transferir o bloco solicitado. Exemplos são teclas de memória USB e unidades de disco.

    5. Fabricantes de equipamentos originais (OEM) Drivers

    Os drivers de dispositivo podem ser categorizados como genéricos ou relacionados ao OEM. Drivers genéricos se referem a drivers de dispositivo com seu software operacional empacotado no hardware OEM. Pode -se usar drivers genéricos com diferentes marcas de um determinado tipo de dispositivo. Por exemplo, o Linux funciona com vários drivers genéricos que funcionam sem a necessidade de instalar qualquer outro software manualmente.

    Os OEMs podem criar seus drivers de dispositivo proprietários, que precisam ser instalados separadamente após a instalação do sistema operacional. Os drivers OEM permitem que hardware como teclados se comuniquem com o sistema operacional host. Por exemplo, os drivers OEM permitem funções, como integrar o sistema de controle de iluminação com hardware OEM no Google Assistant e Alexa.

    6. Drivers de dispositivo virtual

    Os drivers de dispositivos virtuais são essenciais para controlar máquinas ou VMs virtuais . Eles operam em ambientes de virtualização e não virtualização. Nos ambientes de virtualização, esses drivers são usados ​​para imitar o hardware do dispositivo host. Eles controlam ou gerenciam o hardware do recurso do dispositivo host para garantir que o convidado e o dispositivo host sejam executados conforme o esperado.

    Por exemplo, quando um sistema operacional convidado funciona em um host, faz chamadas de função para drivers de dispositivo virtual para acessar o hardware. Além disso, eles imitam ocorrências no nível do processador, como interrupções e transmitem-as para a máquina virtual.

    7. BIOS

    O sistema básico de saída de entrada (BIOS) é o motorista mais fundamental em um computador. Ele está localizado em um chip de memória somente leitura (ROM), que garante que o BIOS esteja disponível mesmo quando o disco rígido for formatado. É responsável por inicializar um computador e fornecer um conjunto de instruções durante esse processo. Ele também realiza auto-testes de poder (post) que são necessários durante a inicialização. O BIOS também fornece drivers para o hardware básico, como teclados e monitores, para garantir que eles interajam com o sistema operacional para funcionar como pretendido.

    8. Motoristas da placa -mãe

    Os drivers da placa -mãe são aplicativos simples que o Windows e o Linux podem utilizar. Eles existem dentro do sistema operacional e permitem operações fundamentais de computador. Esses motoristas compreendem aplicativos que permitem o teclado e o mouse’S Devices USB e portas de E/S para funcionar. Algumas placas -mãe têm drivers que suportam vídeo e áudio.

    Os motoristas da placa -mãe são específicos para o modelo de chipset, como B460 para computadores Intel. Para perceber a placa -mãe’S Potencial total e componentes conectados a ele funcionar corretamente, os usuários podem precisar instalar drivers adicionais.

    9. Motoristas de código aberto

    Motoristas de código aberto se referem a motoristas que são liberados sob uma licença gratuita e de código aberto. Por exemplo, os drivers gráficos de código aberto controlam a saída para a tela se a tela fizer parte do hardware gráfico. O código-fonte para motoristas de código aberto está disponível para todos, facilitando as colaborações de software. Eles são mais confiáveis, pois as pessoas podem verificá -las para qualquer código malicioso.

    Os motoristas de código aberto oferecem mais privacidade. Se eles rastreiam os usuários, as pessoas podem redistribuir uma cópia do software com o rastreamento removido. Os motoristas de código aberto duram mais à medida que mais pessoas continuam fazendo melhorias, garantindo assim que, mesmo quando a empresa parar de distribuí-las, uma cópia permanece.

    Aplicações de drivers de dispositivo

    Esses blocos essenciais de computação pessoal e corporativa são usados ​​das seguintes maneiras:

    1. Drivers de dispositivo para acessar sistemas de armazenamento

    Os sistemas de armazenamento de computador permitem que os usuários armazenem dados e o disponibilizem sob demanda. Eles incluem dispositivos externos e internos, como unidades flash USB, discos rígidos e armazenamento ligado à rede. Os motoristas em sistemas de armazenamento permitem interagir com o computador. Isso garante que o computador possa acessar seus sistemas de armazenamento interno ou externo, consultar suas informações e permitir a transferência de dados.

    Conectar dispositivos de armazenamento ao computador sem motoristas se torna difícil, pois o sistema operacional não os detecta. Geralmente, discos rígidos e CD-ROMs são reconhecidos pelo sistema operacional e não exigem que os motoristas sejam instalados manualmente. Os usuários devem instalar drivers do fabricante’s site se eles não forem detectados automaticamente.

    2. Drivers de dispositivo para dispositivos de entrada e saída

    O computador’S os os interagem com os drivers de dispositivo para garantir suas funções de hardware conforme o esperado. Os dispositivos de entrada incluem ratos e teclados, enquanto os dispositivos de saída incluem dispositivos de exibição, como monitores. Teclados, ratos e monitores são categorizados como dispositivos plug-and-play.

    Geralmente, os drivers para dispositivos plug-and-play são genéricos e não requerem instalação manual, pois o computador’S OS os reconhece e os instala automaticamente. No entanto, se um dispositivo externo não for um dispositivo plug-and-play, os usuários podem precisar instalar manualmente os drivers do disco de instalação ou baixá-los. Isso permitirá que o sistema operacional reconheça esses dispositivos.

    3. Drivers de dispositivo para câmeras digitais

    Um driver de câmera digital é um programa que permite a comunicação entre ele e outros dispositivos, como computadores. Sem os motoristas, o sistema operacional não detectará este dispositivo. A maioria das câmeras digitais é compatível apenas com o sistema operacional Windows, como linux sistemas lagos.

    Os drivers de câmera digital permitem a transferência de fotos da câmera para o computador. Eles permitem que câmeras digitais imprimam fotos usando o padrão PictBridge diretamente para uma impressora de computador com capacidade para pictbridge sem precisar de um computador. Drivers na porta de saída de vídeo permitem que os usuários exibam fotos na televisão selecionando um vídeo ou foto de cada vez.

    4. Drivers para sistemas operacionais móveis como Android

    Os telefones celulares têm motoristas para permitir que eles se comuniquem com computadores. Os motoristas vêm empacotados com o firmware na maioria dos telefones, o que permite que os computadores os carreguem para suportar hardware, pois o sistema operacional não é especificado. No entanto, às vezes os usuários podem precisar instalar o software OEM PC primeiro para os drivers serem instalados e permitir a transferência de dados.

    Os motoristas permitem a integração de dispositivos periféricos, como controladores de jogo ou teclados com base em sistemas operacionais, como Android Things e Android. Os drivers permitem acesso e controle do hardware. Além disso, eles permitem que dispositivos inteligentes funcionem com aplicativos personalizados.

    5. Drivers de dispositivo para desempenho superior de vídeo

    As placas gráficas são componentes principais de um sistema de computador e são responsáveis ​​pelo desempenho de vídeo superior em computadores, jogos ou outras tarefas com uso intensivo de gráficos. Os drivers gráficos permitem que as placas gráficas interajam com o computador’S Sistema Operacional e, portanto, é essencial para obter o melhor desempenho das placas gráficas.

    A atualização de drivers gráficos e outros drivers do Windows 11 (ou mais antigos) pode dar aos usuários um aumento de velocidade, corrigir problemas e, às vezes, até fornecer aos usuários novos recursos. Por exemplo, a atualização dos motoristas de jogo pode aumentar os quadros por segundo, reduzindo o atraso.

    Remover

    À medida que consumidores e empresas usam cada vez mais dispositivos e periféricos, os drivers de dispositivos são essenciais para a infraestrutura de TI . A tecnologia moderna do motorista pode melhorar o funcionamento do computador, reduzindo o consumo de recursos e aumentando a velocidade. É por isso que é necessário saber como os drivers operam e têm um cronograma regular de driver e atualização para que todo o ecossistema de dispositivo funcione sem problemas.

    Você achou este artigo útil ao aprender sobre os drivers de dispositivo? Conte -nos Facebook Abre uma nova janela , Twitter Abre uma nova janela , e LinkedIn Abre uma nova janela . Nós’D Adoro ouvir de você!

    Mais sobre o DevOps

    • Top 10 Certificações do Azure DevOps em 2022
    • O que é o ciclo de vida do DevOps? Definição, componentes -chave e práticas recomendadas de gerenciamento
    • Top 10 Certificações mestre de Scrum em 2022
    • As 18 principais perguntas da entrevista do Azure DevOps em 2022
    • 10 principais certificações e cursos do DevOps em 2022