Arquivo de dispositivo
Em sistemas operacionais, um arquivo de dispositivo, ou arquivo especial, é uma interface para um driver de dispositivo que aparece em um sistema de arquivos como se fosse um arquivo comum. Eles são comumente utilizados em sistemas operacionais do tipo Unix e também são encontrados no MS-DOS, OS/2 e Microsoft Windows. Os arquivos de dispositivo permitem que o software interaja com um driver de dispositivo utilizando as chamadas de sistema (system calls) padronizadas de entrada/saída, o que simplifica muitas tarefas e unifica mecanismos de E/S de espaço do usuário.
Frequentemente, os arquivos de dispositivo são utilizados como simples interfaces para dispositivos periféricos, como impressoras. Mas eles também podem ser usados para o acesso de recursos específicos nestes dispositivos, como partições em um disco. Finalmente, os arquivos de dispositivo são uteís para o acesso a recursos do sistema que não tem conexão com um dispositivo físico, como o /dev/null e geradores de números aleatórios.
Sistemas Unix e do tipo Unix editar
Nós de dispositivo correspondem aos recursos que um núcleo de sistema operacional já alocou. O Unix identifica estes recursos por um número maior e um número menor,[1] ambos armazenados como parte da estrutura de um nó. A designação destes números ocorrem de forma única em diferentes sistemas operacionais e sobre diferentes plataformas de computador. Geralmente, o número maior identifica o controlador (driver) do dispositivo e o menor identifica um dispositivo particular (possivelmente fora de muitos) que o driver controla:[2] neste caso, o sistema pode passar o número menor ao driver. Entretanto, na presença da alocação de números dinâmica, este pode não ser o caso (e.g. no FreeBSD 5 em diante).
Dispositivos de caractere editar
Arquivos especiais de caractere ou dispositivos de caractere fornecem acesso direto, e sem buffer, ao dispositivo de hardware. Eles não necessariamente permitem que os programas leiam ou escrevam caracteres individuais de cada vez, pois isso depende do dispositivo em questão. O dispositivo de caractere para um disco rígido, por exemplo, normalmente exigirá que todas as leituras e gravações sejam alinhadas aos limites de bloco e certamente não permitirá a leitura de um único byte.
Os dispositivos de caractere às vezes são conhecidos como dispositivos brutos, para evitar a confusão em torno do fato de que um dispositivo de caractere, para um pedaço de hardware baseado em bloco, normalmente exigirá que os programas leiam e gravem blocos alinhados.
Dispositivos de bloco editar
Arquivos especiais de bloco ou dispositivos de bloco fornecem acesso armazenado em memória temporária (buffer) para dispositivos de hardware e fornecem alguma abstração de suas especificidades. Diferente de dispositivos de caractere, dispositivos de bloco sempre permitirão ao programador ler e escrever um bloco de qualquer tamanho (incluindo simples caracteres/bytes) e qualquer alinhamento. A desvantagem é que devido aos dispositivos de bloco serem armazenados em memória temporária, o programador não sabe quanto tempo levará antes que os dados escritos sejam passados das memórias temporárias do núcleo para o dispositivo real, ou mesmo em que ordem duas escritas separadas chegarão ao dispositivo físico. Além disso, se o mesmo hardware expõe tanto dispositivos de caractere quanto em bloco, há um risco de corrupção de dados devido aos clientes que utilizam o dispositivo de caractere não terem o conhecimento das alterações feitas na memória temporária (buffer) do dispositivo de bloco.
A maioria dos sistemas criam tanto dispositivos de bloco quanto de caractere para representar o hardware, como discos rígidos. O FreeBSD e o Linux notavelmente não fazem isso. O FreeBSD removeu o suporte para dispositivos de bloco, enquanto o Linux cria apenas dispositivos de bloco. No Linux, para obter um dispositivo de caractere para um disco deve-se usar o controlador (driver) "nativo" (raw), assim pode-se obter o mesmo efeito que abrir um dispositivo de caractere abrindo-se o dispositivo de bloco com a flag específica do Linux 0_DIRECT.
Pseudo-dispositivos editar
Os nós de dispositivos em sistemas do tipo Unix não precisam necessariamente corresponder a dispositivos físicos. Os nós que não possuem essa correspondência formam o grupo de pseudo-dispositivos. Eles fornecem várias funções gerenciadas pelo sistema operacional. Alguns dos pseudo-dispositivos mais usados (baseados em caracteres) incluem:
- /dev/null - aceita e descarta todas as entradas. Não produz saída (sempre retorna uma indicação de fim de arquivo em uma leitura)
- /dev/zero - aceita e descarta todas as entradas. Produz um fluxo contínuo de bytes NUL (valor zero)
- /dev/full - produz um fluxo contínuo de bytes NUL (valor zero) quando lido e retorna uma mensagem "disco cheio" quando escrito
- /dev/random e /dev/urandom - eles produzem um fluxo de comprimento variável de números pseudo-aleatórios
devfs editar
devfs é uma implementação específica de um sistema de arquivos de dispositivo em sistemas operacionais do tipo Unix, usada para apresentar arquivos de dispositivo. O mecanismo subjacente de implementação pode variar dependendo do SO.
Manter esses arquivos especiais em um sistema de arquivos implementado fisicamente (por exemplo, disco rígido) é inconveniente, e como ele precisa da assistência do kernel de qualquer maneira, a ideia surgiu de um sistema de arquivos lógico de propósito especial que não é armazenado fisicamente.
Definir, também, quando os dispositivos estão prontos para aparecer não é totalmente trivial. A abordagem 'devfs' é para o driver de dispositivo solicitar a criação e a exclusão de entradas 'devfs' relacionadas aos dispositivos que ele ativa e desativa.
Implementações editar
| Sistema Operacional | Sistema de arquivos ou software de gerenciamento | Ponto de montagem padrão | Autor | Observações |
|---|---|---|---|---|
| Linux 2.3.46pre5–2.6.17 | devfsd | /dev
|
Richard Gooch | Implementado completamente no núcleo. Obsoleto - os usuários são encorajados a migrarem para o udev e/ou devtmpfs. |
| Linux 2.5– | udev em qualquer sistema de arquivos, mas normalmente em tmpfs | /dev
|
Greg Kroah-Hartman, Kay Sievers e Dan Stekloff | Implementado amplamente no espaço do usuário, as informações de dispositivo são reunidas a partir do sysfs. Arquivos de dispositivo podem ser armazenados em um sistema de arquivos de propósito geral, ou em um sistema de arquivos em memória (tmpfs). |
| Linux 2.6.32– | devtmpfs com ou sem udev | /dev
|
Kay Sievers, Jan Blunck, Greg Kroah-Hartman | Uma abordagem híbrida do kernel/espaço do usuário de um sistema de arquivos de dispositivo para fornecer nós antes do udev ser executado pela primeira vez[3] |
| Solaris | /devices
|
Sun Microsystems | Introduzido com controladores (drivers) carregados dinamicamente no Solaris-2.1 | |
| FreeBSD 2.0– | devfs | /dev
|
Poul-Henning Kamp | Implementado completamente no núcleo. |
| DragonFly BSD 2.3.2– | devfs | /dev
|
Alex Hornung | Implementado completamente no núcleo. |
| macOS | devfs | /dev
|
Apple Inc. | Implementado completamente no núcleo. |
| HP-UX B.11.31 | devfs | /dev
|
HP | Implementado completamente no núcleo. |
| Plan 9 | #
|
Bell Labs | Implementado no núcleo. | |
| RISC OS | DeviceFS | Devices:
|
Acorn Computers | O DeviceFS foi iniciado em 1991[4] e apareceu pela primeira vez no RISC OS 3. Ele gerencia vários dispositivos, como arquivos especiais, mais comumente: Paralelo, Serial, FastParallel e USB. O módulo SystemDevices implementa os pseudo-dispositivos, como: Vdu, Kbd, Null e Printer. |
| MS-DOS, PC DOS, DR-DOS | FAT | \DEV (e /DEV)
|
vários | Conforme implementado no núcleo, os dispositivos de caracteres aparecem no diretório virtual \DEV e em qualquer diretório de disco. No MS-DOS/PC DOS 2.x, a diretiva CONFIG.SYS AVAILDEV=FALSE pode ser usada para forçar a existência de dispositivos somente em DEV. |
| MagiC, MiNT, MultiTOS | U:\DEV[5][6]
|
Application Systems Heidelberg, Eric R. Smith, Atari Corp. | A unidade especial U: contem um diretório DEV virtual, dentro do qual pode-se encontrar arquivos de dispositivo. | |
| Windows 9x | \\devices\
|
Microsoft | ||
| Windows NT | \\.\ | Microsoft | O prefixo \\.\ faz com que as APIs de suporte acessem o espaço de nomes do dispositivo Win32 em vez do espaço de nomes do arquivo Win32. O espaço de nomes do dispositivo Win32, em si, vive em \Devices no espaço de nomes do NT.
|
MS-DOS editar
O MS-DOS emprestou o conceito de arquivos especiais do Unix, mas os renomeou para dispositivos.[7] Devido ao fato de versões antigas do MS-DOS não suportarem hierarquia de diretórios, os dispositivos eram diferenciados dos arquivos regulares pelo uso de palavras reservadas para nomeá-los. Isto significa que certos nomes de arquivo são reservados para dispositivos, e não devem ser utilizados para nomear arquivos ou diretórios.[8]
Os nomes reservados, por sua vez, foram criados para serem compatíveis com a manipulação de "arquivos especiais" por parte do comando PIP no CP/M.
Havia dois tipos de dispositivos no MS-DOS: Dispositivos de Bloco (usados para unidades de disco) e Dispositivos de Caractere (geralmente todos os outros dispositivos, incluindo dispositivos COM e PRN).[9] O PIPE, MAILSLOT e MUP são outros padrões de dispositivos do Windows.[10]
DOS, TOS, OS/2 e Windows editar
Um arquivo de dispositivo é uma palavra-chave reservada usada nos sistemas DOS, TOS, OS/2 e Microsoft Windows para permitir acesso a certas portas e dispositivos.
O DOS usa arquivos de dispositivo para acessar impressoras e portas. A maioria das versões do Windows também contem este suporte, que pode causar confusão ao tentar criar arquivos e pastas de determinados nomes, quando eles não puderem possuir esses nomes.[11] As versões 2.x do MS-DOS fornecem o parâmetro AVAILDEV do CONFIG.SYS que, se definido como FALSE, torna esses nomes especiais ativos apenas se prefixados com \DEV\, permitindo assim que arquivos ordinários sejam criados com esses nomes.[12]
O GEMDOS, a parte derivada do DOS do Atari TOS, suportava nomes de dispositivos similares ao DOS, porém, diferente do DOS, era necessário um caractere ":" (no DOS, isto é opcional) para identificá-los como dispositivos, em oposição aos nomes de arquivos normais (desta forma, "CON:" funcionaria tanto no DOS quando no TOS, mas "CON" poderia nomear um arquivo ordinário no TOS, mas nomearia o dispositivo de console no DOS). No MiNT e no MagiC, uma visão especial do sistema de arquivos unificado do tipo Unix, acessada por meio da letra de unidade "U:", também colocava arquivos de dispositivo em "U:\DEV".
Alguns dos arquivos de dispositivo são listados abaixo:
| Nome do arquivo | propósito |
|---|---|
| CON | dispositivo de console |
| PRN | impressora |
| AUX | Dispositivo auxiliar |
| COM0 COM1 COM2 COM3 COM4 COM5 COM6 COM7 COM8 COM9 | portas seriais |
| LPT1 LPT2 PRN | portas paralelas |
| NUL | Bit bucket |
Uma palavra reservada não pode sequer ser utilizada como extensão de arquivo, os nomes de arquivo "nul.doc" e "con.html" são inválidos. Isto acaba confundindo usuários leigos e aborrecendo usuários técnicos.
A documentação da Microsoft se refere aos "arquivos de dispositivo MS-DOS" mesmo no sistema Windows NT, que não é baseado no MS-DOS.
Referências
- ↑ Brian W. Kernighan; Rob Pike (1984). The UNIX Programming Environment. [S.l.]: Prentice-Hall. p. 66. ISBN 0-13-937681-X
- ↑ Neil Brown (27 de outubro de 2010). «Ghosts of Unix Past: a historical search for design patterns». LWN.net. Consultado em 30 de março de 2014
- ↑ «Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev». LWN. Consultado em 10 de agosto de 2009
- ↑ «Project Black change log». Consultado em 15 de maio de 2016
- ↑ «The drive U: in MagiC». 28 de março de 2016. Consultado em 9 de janeiro de 2017. Cópia arquivada em 15 de janeiro de 2017
- ↑ «FreeMiNT-Portal - mint.doc». 27 de abril de 2000. Consultado em 9 de janeiro de 2017. Cópia arquivada em 15 de janeiro de 2017
- ↑ «Windows for Workgroups: How VSHARE.386 Manages File Sharing». Support.microsoft.com. 22 de setembro de 1999. Consultado em 22 de janeiro de 2014
- ↑ «Avoid Creating Macintosh Filenames that are NT Device Names». Support.microsoft.com. 1 de novembro de 2006. Consultado em 22 de janeiro de 2014
- ↑ «device attributes». Stanislavs.org. Consultado em 22 de janeiro de 2014
- ↑ «REG: CurrentControlSet Entries PART 2: SessionManager». Support.microsoft.com. 1 de novembro de 2006. Consultado em 22 de janeiro de 2014
- ↑ «MS-DOS Device Driver Names Cannot be Used as File Names». Microsoft. 12 de maio de 2003. Consultado em 1 de maio de 2008
- ↑ «Undocumented Commands». 4dos.info. Kevtronics. 12 de abril de 2002. Consultado em 16 de maio de 2014
