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.

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).

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.

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.

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 é 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.

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]

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:

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

1. ↑ Brian W. Kernighan; Rob Pike (1984). The UNIX Programming Environment. [S.l.]: Prentice-Hall. p. 66. ISBN 0-13-937681-X 
2. ↑ 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 
3. ↑ «Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev». LWN. Consultado em 10 de agosto de 2009 
4. ↑ «Project Black change log». Consultado em 15 de maio de 2016 
5. ↑ «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 
6. ↑ «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 
7. ↑ «Windows for Workgroups: How VSHARE.386 Manages File Sharing». Support.microsoft.com. 22 de setembro de 1999. Consultado em 22 de janeiro de 2014 
8. ↑ «Avoid Creating Macintosh Filenames that are NT Device Names». Support.microsoft.com. 1 de novembro de 2006. Consultado em 22 de janeiro de 2014 
9. ↑ «device attributes». Stanislavs.org. Consultado em 22 de janeiro de 2014 
10. ↑ «REG: CurrentControlSet Entries PART 2: SessionManager». Support.microsoft.com. 1 de novembro de 2006. Consultado em 22 de janeiro de 2014 
11. ↑ «MS-DOS Device Driver Names Cannot be Used as File Names». Microsoft. 12 de maio de 2003. Consultado em 1 de maio de 2008 
12. ↑ «Undocumented Commands». 4dos.info. Kevtronics. 12 de abril de 2002. Consultado em 16 de maio de 2014 

Este artigo sobre sistema operacional é um esboço. Você pode ajudar a Wikipédia expandindo-o. v d e