Por que o / dev / null é um arquivo? Por que sua função não é implementada como um programa simples?

Estou tentando entender o conceito de arquivos especiais no Linux. No entanto, ter um arquivo especial em /devparece tolo quando sua função pode ser implementada por um punhado de linhas em C, que eu saiba.

Além disso, você pode usá-lo da mesma maneira, ou seja, canalizando em nullvez de redirecionar para /dev/null. Existe um motivo específico para tê-lo como um arquivo? Criar um arquivo não causa muitos outros problemas, como muitos programas acessando o mesmo arquivo?

Além dos benefícios de desempenho do uso de um dispositivo especial para caracteres, o principal benefício é a modularidade . / dev / null pode ser usado em praticamente qualquer contexto em que um arquivo é esperado, não apenas em pipelines de shell. Considere programas que aceitam arquivos como parâmetros de linha de comando.

# We don't care about log output.
$ frobify --log-file=/dev/null

# We are not interested in the compiled binary, just seeing if there are errors.
$ gcc foo.c -o /dev/null  || echo "foo.c does not compile!".

# Easy way to force an empty list of exceptions.
$ start_firewall --exception_list=/dev/null

Esses são todos os casos em que o uso de um programa como fonte ou coletor seria extremamente complicado. Mesmo no caso do pipeline do shell, stdout e stderr podem ser redirecionados para arquivos de forma independente, algo difícil de fazer com executáveis ​​como coletores:

# Suppress errors, but print output.
$ grep foo * 2>/dev/null

Para ser justo, não é um arquivo comum por si só; é um dispositivo especial para personagens :

$ file /dev/null
/dev/null: character special (3/2)

Funcionar como um dispositivo, e não como um arquivo ou programa, significa que é uma operação mais simples redirecionar a entrada ou saída a partir dele, pois pode ser anexada a qualquer descritor de arquivo, incluindo entrada / saída / erro padrão.

Suspeito que o porquê tenha muito a ver com a visão / design que moldou o Unix (e, consequentemente, o Linux), e as vantagens decorrentes dele.

Sem dúvida, há um benefício de desempenho não negligenciável em não gerar um processo extra, mas acho que há mais: o Early Unix tinha uma metáfora "tudo é um arquivo", que tem uma vantagem não óbvia, mas elegante, se você olhar para do ponto de vista do sistema, em vez de uma perspectiva de script de shell.

Digamos que você tenha seu nullprograma de linha de comando e /dev/nullo nó do dispositivo. De uma perspectiva de script de shell, o foo | nullprograma é realmente realmente útil e conveniente , e foo >/dev/nulldemora um pouco mais para digitar e pode parecer estranho.

Mas aqui estão dois exercícios:

1. Vamos implementar o programa nullusando ferramentas existentes Unix e /dev/null- fácil: cat >/dev/null. Feito.

2. Você pode implementar /dev/nullem termos de null?

Você está absolutamente certo de que o código C para descartar apenas a entrada é trivial; portanto, talvez ainda não seja óbvio por que é útil ter um arquivo virtual disponível para a tarefa.

Considere: quase todas as linguagens de programação já precisam trabalhar com arquivos, descritores e caminhos de arquivos, porque faziam parte do paradigma "tudo é um arquivo" do Unix desde o início.

Se tudo o que você tem são programas que gravam no stdout, bem, o programa não se importa se você os redirecionar para um arquivo virtual que engole todas as gravações ou um canal para um programa que engole todas as gravações.

Agora, se você possui programas que utilizam caminhos de arquivos para leitura ou gravação de dados (o que a maioria dos programas faz) - e deseja adicionar a funcionalidade "entrada em branco" ou "descartar esta saída" a esses programas - bem, /dev/nullisso é de graça.

Observe que a elegância disso é que reduz a complexidade do código de todos os programas envolvidos - para cada caso de uso comum, mas especial, que o sistema pode fornecer como "arquivo" com um "nome do arquivo" real, seu código pode evitar adicionar comandos personalizados opções de linha e caminhos de código personalizados para manipular.

A boa engenharia de software geralmente depende da descoberta de metáforas boas ou "naturais" para abstrair algum elemento de um problema de uma maneira que se torna mais fácil de pensar, mas permanece flexível , para que você possa resolver basicamente a mesma faixa de problemas de nível superior sem precisar gaste tempo e energia mental reimplementando soluções para os mesmos problemas de nível inferior constantemente.

"Tudo é um arquivo" parece ser uma metáfora para acessar recursos: você chama openum determinado caminho em um espaço de nome heirárquico, obtendo uma referência (descritor de arquivo) ao objeto e pode reade writeetc nos descritores de arquivo. Seu stdin / stdout / stderr também são descritores de arquivos que foram pré-abertos para você. Seus pipes são apenas arquivos e descritores de arquivos, e o redirecionamento de arquivos permite colar todas essas peças.

O Unix conseguiu tanto quanto em parte por causa de quão bem essas abstrações funcionaram juntas, e /dev/nullé melhor entendido como parte desse todo.

PS Vale a pena olhar para a versão Unix de "tudo é um arquivo" e coisas como /dev/nullos primeiros passos para uma generalização mais flexível e poderosa da metáfora que foi implementada em muitos sistemas que se seguiram.

Por exemplo, no Unix, objetos especiais semelhantes a arquivos /dev/nulltiveram que ser implementados no próprio kernel, mas acontece que é útil o suficiente para expor a funcionalidade no formato de arquivo / pasta que, desde então, foram criados vários sistemas que possibilitam programas fazer isso.

Um dos primeiros foi o sistema operacional Plan 9, feito por algumas das mesmas pessoas que criaram o Unix. Mais tarde, o GNU Hurd fez algo semelhante com seus "tradutores". Enquanto isso, o Linux acabou recebendo o FUSE (que já se espalhou para outros sistemas convencionais).

Eu acho que /dev/nullé um dispositivo de caractere (que se comporta como um arquivo comum) em vez de um programa por razões de desempenho .

Se fosse um programa, seria necessário carregar, iniciar, agendar, executar e, posteriormente, interromper e descarregar o programa. O programa C simples que você está descrevendo obviamente não consumiria muitos recursos, mas acho que faz uma diferença significativa ao considerar um grande número (digamos milhões) de ações de redirecionamento / canalização, pois as operações de gerenciamento de processo são caras em larga escala, pois eles envolvem opções de contexto.

Outra suposição: a inserção em um programa requer que a memória seja alocada pelo programa receptor (mesmo que seja descartada diretamente posteriormente). Portanto, se você acessar a ferramenta, terá um consumo de memória dupla, uma vez no programa de envio e novamente no programa de recebimento.

Além de "tudo é um arquivo" e, portanto, a facilidade de uso em qualquer lugar em que a maioria das outras respostas se baseia, também há um problema de desempenho como o @ user5626466 menciona.

Para mostrar na prática, criaremos um programa simples chamado nullread.c:

#include <unistd.h>
char buf[1024*1024];
int main() {
        while (read(0, buf, sizeof(buf)) > 0);
}

e compilá-lo com gcc -O2 -Wall -W nullread.c -o nullread

(Nota: não podemos usar lseek (2) em tubos, portanto, a única maneira de drená-lo é lê-lo até que esteja vazio).

% time dd if=/dev/zero bs=1M count=5000 |  ./nullread
5242880000 bytes (5,2 GB, 4,9 GiB) copied, 9,33127 s, 562 MB/s
dd if=/dev/zero bs=1M count=5000  0,06s user 5,66s system 61% cpu 9,340 total
./nullread  0,02s user 3,90s system 41% cpu 9,337 total

enquanto que com /dev/nullo redirecionamento de arquivo padrão , obtemos velocidades muito melhores (devido aos fatos mencionados: menos troca de contexto, o kernel apenas ignora os dados em vez de copiá-los, etc.):

% time dd if=/dev/zero bs=1M count=5000 > /dev/null
5242880000 bytes (5,2 GB, 4,9 GiB) copied, 1,08947 s, 4,8 GB/s
dd if=/dev/zero bs=1M count=5000 > /dev/null  0,01s user 1,08s system 99% cpu 1,094 total

(este deve ser um comentário, mas é grande demais para isso e seria completamente ilegível)

Sua pergunta é colocada como se algo fosse ganho talvez em simplicidade usando um programa nulo no lugar de um arquivo. Talvez possamos nos livrar da noção de "arquivos mágicos" e, em vez disso, ter apenas "tubos comuns".

Mas considere, um cachimbo também é um arquivo . Eles normalmente não são nomeados e, portanto, só podem ser manipulados através de seus descritores de arquivo.

Considere este exemplo um tanto artificial:

$ echo -e 'foo\nbar\nbaz' | grep foo
foo

Usando a substituição de processos do Bash, podemos realizar a mesma coisa de uma maneira mais indireta:

$ grep foo <(echo -e 'foo\nbar\nbaz')
foo

Substitua o grepfor echoe podemos ver embaixo das tampas:

$ echo foo <(echo -e 'foo\nbar\nbaz')
foo /dev/fd/63

A <(...)construção é substituída apenas por um nome de arquivo, e o grep acha que está abrindo qualquer arquivo antigo, apenas recebe o nome /dev/fd/63. Aqui /dev/fdestá um diretório mágico que cria pipes nomeados para todos os descritores de arquivos possuídos pelo arquivo que os acessa.

Poderíamos tornar menos mágico mkfifocriar um pipe nomeado que apareça em lstudo, como um arquivo comum:

$ mkfifo foofifo
$ ls -l foofifo 
prw-rw-r-- 1 indigo indigo 0 Apr 19 22:01 foofifo
$ grep foo foofifo

Em outro lugar:

$ echo -e 'foo\nbar\nbaz' > foofifo

e eis que grep será exibido foo.

Eu acho que depois que você perceber que pipes e arquivos regulares e arquivos especiais como / dev / null são apenas arquivos, é evidente que a implementação de um programa nulo é mais complexa. O kernel tem que lidar com gravações em um arquivo de qualquer maneira, mas no caso de / dev / null, ele pode simplesmente soltar as gravações no chão, enquanto que com um pipe ele precisa realmente transferir os bytes para outro programa, que então precisa realmente lê-los.

Eu argumentaria que há um problema de segurança além dos paradigmas históricos e do desempenho. Limitar o número de programas com credenciais de execução privilegiadas, não importa quão simples, é um princípio fundamental da segurança do sistema. Uma substituição /dev/nullcertamente seria necessária para ter esses privilégios devido ao uso pelos serviços do sistema. As estruturas de segurança modernas fazem um excelente trabalho impedindo explorações, mas não são infalíveis. Um dispositivo controlado por kernel acessado como um arquivo é muito mais difícil de explorar.

Como outros já apontaram, /dev/null é um programa feito de algumas linhas de código. É só que essas linhas de código fazem parte do kernel.

Para deixar mais claro, aqui está a implementação do Linux: um dispositivo de caractere chama funções quando é lido ou gravado. Gravando para /dev/nullchamadas write_null , enquanto lê chamadas read_null , registradas aqui .

Literalmente, algumas linhas de código: essas funções não fazem nada. Você precisaria de mais linhas de código do que dedos nas mãos apenas se contar outras funções além de ler e escrever.

Espero que você também esteja ciente do / dev / chargen / dev / zero e outros como eles, incluindo / dev / null.

O LINUX / UNIX possui alguns deles - disponibilizados para que as pessoas possam fazer bom uso das fragmentos de códigos bem escritos.

O Chargen foi projetado para gerar um padrão específico e repetitivo de caracteres - é bastante rápido e aumentaria os limites de dispositivos seriais e ajudaria a depurar protocolos seriais que foram escritos e falharam em algum teste ou outro.

Zero é projetado para preencher um arquivo existente ou gerar muitos zeros

/ dev / null é apenas mais uma ferramenta com a mesma idéia em mente.

Todas essas ferramentas no seu kit de ferramentas significam que você tem meia chance de fazer com que um programa existente faça algo único, sem levar em consideração a (sua necessidade específica) como dispositivos ou substituições de arquivos

Vamos criar um concurso para ver quem pode produzir o resultado mais emocionante, considerando apenas os poucos dispositivos de caracteres na sua versão do LINUX.