Isso porque /proc
(e /sys
) são interfaces de kernel. Nada lá é um arquivo real no disco. A informação vem diretamente do sistema operacional. Os arquivos individuais são como interfaces de soquete e, quando você os lê, está fazendo uma solicitação de dados.
O sistema de arquivos proc aparentemente se origina com o UNIX 8 (embora a implementação do Linux, como a maioria das outras implementações, tenha sido clonada do Plan 9 da Bell Labs) e está de acordo com o ditado "tudo é um arquivo" do UNIX. Ele representa principalmente processos de execução individuais (os números de nível superior são pids), mas pode, como você observou, incluir algumas outras coisas também - o que se sobrepõe ao Linux com o mais orientado a hardware /sys
.
Como nota, às vezes vejo pessoas procurando por "melhores alternativas" para obter as informações do processo programaticamente, em que "melhores alternativas" significa chamadas do sistema como sysctl()
ou ioctl()
. Isso parece estar enraizado no equívoco de que a leitura de arquivos proc ou sys envolve alguma sobrecarga de E / S, como a leitura de um arquivo normal. Não, e enquanto alguns sistemas operacionais (FreeBSD, eu acho) fizeram o oposto, no Linux sysctl()
as chamadas foram depreciadas:
De man 2 sysctl :
use of this system call has long been discouraged, and it is so unloved that it is likely to disappear in a future kernel version. Remove it from your programs now; use the /proc/sys interface instead.
Então você tem: no linux pelo menos, procfs é a fonte oficialmente recomendada para informações do kernel. Não há "alternativas melhores".