O que significa quando algo diz que os arquivos do dispositivo UNIX são estáticos?

Question

Eu tenho lido em udev . Na seção "visão geral", a Wikipedia afirma que "ao contrário dos tradicionais sistemas Unix, onde os nós de dispositivos no diretório / dev são um conjunto estático de arquivos, o gerenciador de dispositivos do Linux udev fornece dinamicamente apenas os nós dos dispositivos sistema ".

O que significa quando diz "conjunto estático de arquivos"? Isso significa que sempre há /dev arquivos, mas eles nem sempre apontam para um dispositivo real?

    

Answer 1

Suponho que você esteja se referindo a este parágrafo:

Unlike traditional Unix systems, where the device nodes in the /dev directory have been a static set of files, the Linux udev device manager dynamically provides only the nodes for the devices actually present on a system. Although devfs used to provide similar functionality, Greg Kroah-Hartman cited a number of reasons3 for preferring its implementation over devfs:

A partir da primeira sentença, eles estão se referindo a outros sistemas Unix, nos quais os dispositivos em /dev são estaticamente criados e mantidos desde a reinicialização até a reinicialização. Versões anteriores do Linux (acho que a versão 2.4 do Kernel) também funcionavam dessa maneira, versões mais novas não se comportam mais dessa maneira. Outros Unixes geralmente incluem um conjunto comum de arquivos de dispositivos quando você os instala e, raramente, é necessário criar outros manualmente.

Em 2.4, você pode usar o comando mknod para criar manualmente qualquer arquivo de dispositivo necessário. Por exemplo:

$ mknod ./dev/random b 12 5

OBSERVAÇÃO: Esta afirmação cria o descritor de arquivo /dev/random , como um dispositivo de bloco com número de dispositivo principal de 12 e um número de dispositivo menor de 5.

Arquivos de dispositivos em / dev

O OP fez a seguinte pergunta de acompanhamento sobre a funcionalidade geral do diretório /dev . Aqui está a pergunta dele:

Can you add details on the technical method used to persist device files across reboots? how are they physically stored on disk? did they need special filesystem support?

Ao pesquisar isso, imaginei começar com o projeto Linux From Scratch para ter uma ideia básica de como /dev é gerenciado em versões mais recentes do kernel do Linux. Eu sei que no passado (acho que as versões do Kernel 2.4 e anteriores) o diretório /dev era um conjunto estático de arquivos que literalmente ocupava espaço no disco rígido, mas com o advento de udev e sysfs isso não era mais O caso.

Tradicionalmente, esses arquivos especiais foram criados no momento da instalação pela distribuição, usando o comando mknod . Nos últimos anos, os sistemas Linux começaram a usar udev para gerenciar esses arquivos /dev em tempo de execução. Por exemplo, udev criará nós quando os dispositivos forem detectados e os excluirá quando os dispositivos forem removidos (incluindo dispositivos hotplug em tempo de execução). Dessa forma, o diretório /dev contém (na maioria das vezes) apenas entradas para dispositivos que realmente existem no sistema no momento atual, ao contrário dos dispositivos que podem existir.

Tão longe estão os dias de ter que se preocupar com os arquivos do seu dispositivo em /dev . Este diretório agora é completamente gerenciado por udev e sysfs da reinicialização para reinicialização.

% adicional% co_de & udev resources

• tutorial do libudev e do Sysfs
• 7.4. Manipulação de dispositivos e módulos em um sistema LFS
• Linux para artigos da revista You - Uma série de drivers de dispositivos Linux

Referências

• Crie arquivos especiais com ‘mknod’
• Especificações do Open Group Base Issue 6 - mknod

Answer 2

"arquivos de dispositivo" são um tipo especial de arquivo (quase da mesma forma que diretórios, links simbólicos, pipes nomeados e soquetes de domínio unix são tipos especiais de arquivos). Eles não armazenam dados do usuário diretamente, em vez disso, armazenam um número de dispositivo maior e menor e um tipo de dispositivo (caractere ou bloco). Sistemas de arquivos projetados para sistemas semelhantes a unix terão suporte para armazenar arquivos de dispositivos.

Quando um "arquivo de dispositivo" é acessado por um aplicativo ou por meio de um comando de montagem, o número do dispositivo principal e secundário e o tipo de dispositivo são recuperados do sistema de arquivos. Com base nesses números, o kernel seleciona o driver e o abre.

Tradicionalmente, os arquivos de dispositivos apenas existiam em um diretório no sistema de arquivos raiz chamado / dev, geralmente criado por uma ferramenta chamada "MAKEDEV" que lê arquivos de configuração e cria nós de dispositivo. Isto é referido como uma configuração estática e foi usado por muitos anos por praticamente todos os sistemas operacionais baseados em Unix, incluindo o Linux. Existem algumas desvantagens nessa abordagem.

• Arquivos de dispositivos existiam mesmo se o hardware correspondente não estivesse presente no sistema atual. Era difícil dizer o que o hardwas era ou não estava presente.
• Se uma atualização do kernel introduzisse novos tipos de dispositivos, o administrador provavelmente teria que criar nós de dispositivo manualmente para eles.
• Havia um suprimento limitado de números maiores e menores, atribuindo estaticamente um par a cada nó de dispositivo possível (lembre-se de que um dispositivo físico pode ter muitos nós de dispositivos devido ao particionamento) não era dimensionável.

A primeira tentativa do linux em resolver este problema foi chamada devfs (alguns outros sistemas operacionais parecidos com unix também possuem um sistema de arquivos chamado devfs, mas eu não sei os detalhes). Este era um sistema de arquivos virtual onde o kernel forneceria nós de dispositivos. Afinal, foi relativamente natimorto, ele empurrou o seu próprio esquema de nomenclatura de dispositivo não padrão, quer você tenha gostado ou não, e não ofereceu grandes vantagens sobre um static / dev

Mais tarde, o udev apareceu. Isso usou um modelo diferente. Um tmpfs foi montado em / dev e um dameon de espaço de usuário gerenciou os nós de dispositivo nele baseados em notificações do kernel. link

Mais recentemente, também houve algo chamado devtmpfs. Isso parece ser uma espécie de compromisso no qual o kernel cria um conjunto de nós de dispositivos básicos, mas o espaço do usuário pode assumir o controle se for desejada uma funcionalidade mais complexa.

    

Answer 3

No sistema Altos 386 (i386 / SCO SysV Unix), um exemplo de dispositivo estático que precisou ser criado na atualização do kernel (ou reinstalação) foi a grande quantidade de entradas / dev / mt para suportar unidades SCSI HP Dat Tape. . O número principal era para o driver de fita no barramento SCSI e os menores para o número do dispositivo SCSI e os recursos (raw, rewind no rewind). Havia dois barramentos SCSI e eles podiam suportar múltiplas unidades de fita mistas e sistemas de arquivos de extensão HD montados em cada barramento.

Os dev foram apenas entradas no sistema de arquivos raiz feitos com o MAKEDDEV. Para propósitos práticos, eles podem ser vinculados a nomes mais utilizáveis, para que o dispositivo de retrocesso no dispositivo SCSI 5 possa ser vinculado a / dev / st (fita SCSI para distingui-lo de uma unidade DC300 incorporada)

Mais tarde, tivemos que fazer o mesmo quando começamos a usar o Slackware Linux e tivemos que corrigir manualmente o kernel .99b para usar as placas de rede 3Com 3C509b corretamente. Estes tinham conectores cat5, BNC e AUI e o esporte estava obtendo a interface correta durante o boot