Este FAQ descreve o comportamento conhecido da versão beta. A documentação da API e o código são a referência para contratos exatos. Recursos no roadmap são planejados, não garantidos como disponíveis.
É uma biblioteca C99 para Linux e um conjunto de ferramentas que consultam informações de CPU por interfaces locais do kernel, com diagnóstico estruturado e exemplos de monitoramento.
Ainda não. O núcleo atual se concentra em informações da CPU, uso agregado, leitura opcional de temperatura/frequência e diagnóstico. Métricas públicas por CPU lógica, memória/swap/PSI, rede e I/O de armazenamento fazem parte do roadmap de expansão. Acompanhe o roadmap e as issues.
O projeto é direcionado ao Linux. Ele depende de interfaces como /proc e /sys e não oferece suporte nativo a Windows ou macOS.
Não. A biblioteca e os testes do núcleo não dependem de GTK4. O monitor desktop é opcional; o monitor de terminal é outro frontend opcional que depende de ncurses.
git clone https://github.com/mnl-nox/cpu-reader.git
cd cpu-reader
make core
make testConsulte BUILD.md para dependências, monitor de terminal, GTK4 e pacote Debian.
Para o núcleo: Linux, compilador C99, GNU Make e libc de desenvolvimento. O monitor de terminal requer ncurses; a interface desktop requer GTK4; o empacotamento Debian requer ferramentas como dpkg-dev.
Não. O pacote é produzido para a arquitetura do ambiente de build e destina-se a Debian e derivados compatíveis com as dependências declaradas. Verifique a matriz de suporte. Um pacote local ou artefato de CI não é automaticamente uma release oficial.
Alvos como make test-sanitize, make test-security e make test-portable limpam e recompilam com flags diferentes. Não execute esses alvos simultaneamente no mesmo diretório.
O uso é calculado a partir da diferença entre contadores de /proc/stat. Uma única leitura não define um intervalo; a primeira amostra estabelece a referência e uma amostra posterior calcula a variação. Para novos coletores, o roadmap prevê status explícito de baseline.
Ferramentas podem escolher janelas de amostragem, tratamento de iowait e normalização diferentes. Compare leituras feitas em intervalos semelhantes e verifique a semântica da métrica. O CPU Reader usa os contadores agregados de /proc/stat para o cálculo atual.
O kernel, driver, firmware ou máquina virtual pode não expor uma zona térmica compatível. A implementação atual consulta interfaces térmicas reconhecidas em /sys/class/thermal; descoberta geral por /sys/class/hwmon ainda não deve ser presumida. Ausência não significa temperatura zero ou normal.
O driver pode não expor uma interface cpufreq acessível, e o fallback pode usar o primeiro valor cpu MHz de /proc/cpuinfo. Isso pode não representar todos os núcleos nem a frequência base. Consulte arquitetura.
O sistema pode não fornecer os identificadores físicos e de núcleo necessários. Nesse caso, zero significa topologia desconhecida/indisponível, não que o processador não tenha núcleos.
Não. O valor atual vem do campo runnable de /proc/loadavg, que indica processos executáveis/na fila de execução. Não é uma listagem nem a contagem total de processos. A documentação da API registra essa semântica para evitar confusão.
Não. Ausência, falha de leitura, conteúdo inválido e valor válido são situações diferentes. Respeite o status e os valores sentinela documentados. Para diagnóstico estruturado, consulte API de diagnóstico.
Use os cabeçalhos públicos em include/, como cpu.h e cpu_diagnostics.h. Não inclua arquivos internos de src/.
O ponteiro de cpu_get_info() deve ser liberado com cpu_free_info(). Consulte a referência da API para ownership e ciclo de vida.
Elas recebem um objeto de erro pertencente ao chamador e associam o diagnóstico à operação, evitando depender apenas do último erro legado por thread. Leia API de diagnóstico.
Os contextos independentes podem ser usados em paralelo quando cada thread possui seu próprio contexto. Um cpu_usage_context_t mutável não deve ser compartilhado entre threads sem sincronização externa. Configure variáveis CPU_READER_*_PATH antes de iniciar threads; não altere o ambiente concorrentemente com leituras.
É possível integrá-la, mas considere o status beta, os contratos de compatibilidade, os limites de plataforma e a validação necessária para seu caso. Fixe a versão/commit, teste no ambiente-alvo e não trate os resultados como fonte única para decisões críticas.
Não para as operações normais. Não execute como root sem necessidade concreta. Privilégios elevados não garantem que um sensor exista ou que seu valor seja confiável.
Não. Ele observa dados fornecidos pelo sistema operacional, que podem ser virtualizados, limitados por containers, omitidos ou influenciados pelo kernel, driver e firmware. Não oferece atestação criptográfica nem valida calibração física.
A biblioteca consulta interfaces locais; o site do projeto é documentação estática. A publicação manual de logs ou relatórios em issues pode expor detalhes do equipamento. Revise e redija saídas antes de compartilhá-las.
Abra uma issue com versão/commit, distribuição, kernel, arquitetura, passos mínimos para reproduzir e comandos de teste executados. Prefira fixtures sintéticas e remova dados pessoais do log.
Siga a política em SECURITY.md. Não publique detalhes exploráveis em uma issue pública.
No mínimo make test. Para parsing, memória ou cálculos de contadores, execute também make test-sanitize e make test-security. Para GTK4/pacote, execute os alvos correspondentes. Veja guia de QA e relatórios.
Significa que os jobs configurados passaram naquele commit e ambiente. Não garante funcionamento em todo hardware, distribuição ou kernel. Teste em emulação deve ser descrito como emulação, não como hardware nativo.
Por issues com escopo e critérios de aceite, seguidas por PRs pequenos, testes determinísticos e documentação. O roadmap define a sequência atual.
Leia CONTRIBUTING.md, selecione uma issue, preserve a compatibilidade pública e inclua evidências de validação. Declare claramente o que foi testado e o que continua pendente.