As informações que você lê do sistema de arquivos proc não são armazenadas em nenhuma mídia (nem mesmo na RAM); portanto, não há nada a atualizar.
O objetivo do sistema de arquivos proc é permitir que programas do espaço do usuário para obter ou conjunto de dados do kernel usando os simples e do sistema de arquivos familiarizado semântica ( open, close, read, write, lseek), mesmo que os dados que são lidos e escritos não reside em qualquer mídia. Essa decisão de design foi considerada melhor (por exemplo, legível por humanos e facilmente programável) para obter e definir dados cujo formato não pôde ser especificado antecipadamente do que implementar algo como OIDs codificados em ASN1, o que também teria funcionado bem.
Os dados que você vê ao ler a partir do sistema de arquivos proc são gerados imediatamente quando você faz uma leitura a partir do início de um arquivo. Ou seja, fazer a leitura faz com que os dados sejam gerados por uma função de retorno de chamada do kernel específica do arquivo que você está lendo. Fazer um lseekpara o início do arquivo e ler novamente causa outra chamada para o retorno de chamada que gera os dados novamente. Da mesma forma, quando você grava em um arquivo gravável no sistema de arquivos proc, é chamada uma função de retorno de chamada que analisa a entrada e define as variáveis do kernel. Os dados de entrada em sua forma bruta não são armazenados.
O exposto acima é apenas uma maneira um pouco mais detalhada de dizer o que Hauke Laging afirma de maneira tão sucinta. Eu sugiro que você aceite a resposta dele.
Se você precisar provar que essa resposta é verdadeira, tente executar o inotify em um "arquivo" ou diretório em / proc (ou / sys) ... é muito ruim, isso tornaria o udev completamente desnecessário se você pudesse apenas dizer um processo inotify simples para executar x quando aparece algo em y
Technosaurus
24
É atualizado a cada acesso. Você vê o estado do kernel naquele momento. É por isso que o tamanho mostrado para os "arquivos" não é o tamanho real. O tamanho real pode mudar e é determinado no momento em que você acessa o arquivo.
Você poderia dizer que pode não ser atualizado por dias. Se você não olhar para isso. :-)
+1. É um pouco como o ditado: "Se uma árvore cai em uma floresta e ninguém está por perto para ouvi-la, ela produz um som?", Ou seja, "Se existe um sistema de arquivos proc e ninguém lê, existe ? "
Jonathan Ben-Avraham
@ JonathanBen-Avraham Você poderia dizer isso sobre todos os FS, não poderia? :-) Mas lembre-se de que existem muito mais acessos para proc do que se poderia imaginar. Comentá-la no fstab, reiniciar, e todo o inferno quebra solto ...
Hauke Laging
O que eu quis dizer foi que os dados em um sistema de arquivos com suporte de mídia existem mesmo quando ninguém os lê em um determinado momento. Ele não existe no momento da leitura como proc e sys. Você está correto, proc tem muitos leitores. No entanto, sys é um sistema de arquivos semelhante que você pode comentar no fstab, pelo menos em sistemas menores e ainda executar o Ok. Felicidades.
Jonathan Ben-Avraham
4
Então o gato está morto ou não? Dê uma olhada e veja. Jim morto. Pobre gato.
0x7c0
@HaukeLaging Não tenho o /proc/arquivo fstab no meu ☹ #:
Respostas:
As informações que você lê do sistema de arquivos proc não são armazenadas em nenhuma mídia (nem mesmo na RAM); portanto, não há nada a atualizar.
O objetivo do sistema de arquivos proc é permitir que programas do espaço do usuário para obter ou conjunto de dados do kernel usando os simples e do sistema de arquivos familiarizado semântica (
open,close,read,write,lseek), mesmo que os dados que são lidos e escritos não reside em qualquer mídia. Essa decisão de design foi considerada melhor (por exemplo, legível por humanos e facilmente programável) para obter e definir dados cujo formato não pôde ser especificado antecipadamente do que implementar algo como OIDs codificados em ASN1, o que também teria funcionado bem.Os dados que você vê ao ler a partir do sistema de arquivos proc são gerados imediatamente quando você faz uma leitura a partir do início de um arquivo. Ou seja, fazer a leitura faz com que os dados sejam gerados por uma função de retorno de chamada do kernel específica do arquivo que você está lendo. Fazer um
lseekpara o início do arquivo e ler novamente causa outra chamada para o retorno de chamada que gera os dados novamente. Da mesma forma, quando você grava em um arquivo gravável no sistema de arquivos proc, é chamada uma função de retorno de chamada que analisa a entrada e define as variáveis do kernel. Os dados de entrada em sua forma bruta não são armazenados.O exposto acima é apenas uma maneira um pouco mais detalhada de dizer o que Hauke Laging afirma de maneira tão sucinta. Eu sugiro que você aceite a resposta dele.
fonte
É atualizado a cada acesso. Você vê o estado do kernel naquele momento. É por isso que o tamanho mostrado para os "arquivos" não é o tamanho real. O tamanho real pode mudar e é determinado no momento em que você acessa o arquivo.
Você poderia dizer que pode não ser atualizado por dias. Se você não olhar para isso. :-)
fonte
/proc/arquivo fstab no meu ☹ #: