Scalablity

Futuro da Biblioteca

Visão de futuro

O objetivo futuro do CPU Reader é evoluir de uma biblioteca simples de leitura de informações da CPU para uma biblioteca de monitoramento de hardware e recursos do sistema, mantendo como princípios a simplicidade, baixo acoplamento, portabilidade e acesso direto às interfaces do sistema operacional.

A evolução deve ocorrer de forma incremental, preservando a API existente sempre que possível.

Evolução da coleta de dados

Uma das principais direções é ampliar a quantidade e a qualidade das informações coletadas.

Possíveis extensões:

• utilização individual por núcleo;
• frequência atual e máxima por núcleo;
• temperatura por sensor;
• identificação de diferentes sensores térmicos;
• estados de energia da CPU;
• informações de arquitetura;
• número de sockets, cores e threads;
• informações de cache;
• informações adicionais disponíveis pelo kernel.

A biblioteca poderá futuramente organizar essas informações em estruturas mais completas, permitindo que uma aplicação escolha exatamente quais métricas deseja consultar.

Monitoramento em tempo real

Outra direção importante é melhorar o suporte ao monitoramento contínuo.

Atualmente o projeto já possui um monitor de terminal baseado em ncurses.

No futuro, esse componente poderá evoluir para apresentar:

CPU
├── Uso total
├── Uso por núcleo
├── Frequência
├── Temperatura
├── Processos
└── Histórico

Também poderá ser implementado um histórico das métricas, permitindo visualizar a variação da utilização da CPU ao longo do tempo.

Portabilidade

A biblioteca atualmente possui uma implementação específica para x86_64 utilizando assembly inline em determinadas operações, além de fallback em C para outras plataformas.

Uma meta futura é ampliar o suporte para diferentes arquiteturas, mantendo uma camada de abstração capaz de separar:

API pública
     ↓
camada de abstração
     ↓
implementação específica
     ↓
arquitetura / sistema operacional

Isso pode facilitar futuramente o suporte a arquiteturas como:

• x86;
• x86_64;
• ARM;
• ARM64;
• outras arquiteturas compatíveis.

Portabilidade entre sistemas Unix

Embora o foco atual seja Linux, a arquitetura pode futuramente ser preparada para outros sistemas Unix-like.

A ideia seria separar as partes específicas do Linux da API genérica:

                 CPU Reader
                     │
              API independente
                     │
          ┌──────────┼──────────┐
          ↓          ↓          ↓
        Linux      BSD       Outros Unix
        /proc     sysctl      backend
        sysfs

Isso permitiria preservar a mesma interface de programação enquanto o mecanismo interno de coleta de dados varia de acordo com o sistema operacional.

API e estabilidade

À medida que a biblioteca crescer, será importante estabelecer uma política clara de compatibilidade da API.

A evolução poderá seguir princípios como:

• evitar alterações incompatíveis sem necessidade;
• documentar mudanças de API;
• utilizar versionamento semântico;
• manter funções existentes durante períodos de transição;
• adicionar novas funcionalidades de maneira incremental.

O projeto já utiliza versionamento no formato MAJOR.MINOR.PATCH, com automação baseada nos tipos de commit.

Segurança e robustez

O crescimento da biblioteca também deverá ser acompanhado por melhorias de robustez.

Entre os objetivos:

• validação rigorosa das entradas;
• tratamento consistente de erros;
• prevenção de vazamentos de memória;
• tratamento de arquivos inexistentes;
• tratamento de sensores indisponíveis;
• validação dos dados fornecidos pelo sistema;
• maior cobertura de testes;
• comportamento previsível em sistemas com configurações diferentes.

Um ponto importante será evitar que uma falha em uma métrica torne toda a biblioteca inutilizável.

Por exemplo, a ausência de um sensor de temperatura não deve impedir a leitura de utilização ou frequência.

Thread-safety

O mecanismo atual de erro é global e não é thread-safe.

Uma evolução natural será permitir o uso da biblioteca em aplicações multithread de maneira mais segura.

Isso poderá envolver:

• contexto por instância;
• estado de erro associado ao contexto;
• eliminação de estado global;
• APIs reentrantes;
• documentação explícita das garantias de concorrência.

A estrutura cpu_usage_context_t já representa uma direção interessante nesse sentido, pois permite manter estados independentes para o cálculo de utilização.

Testes

A suíte de testes deverá acompanhar a expansão da biblioteca.

Além dos testes básicos atuais, poderão ser adicionados testes para:

entrada válida
entrada inválida
arquivo inexistente
arquivo malformado
sensor indisponível
CPU sem cpufreq
erro de memória
múltiplos contextos
concorrência
diferentes arquiteturas

O uso das variáveis de ambiente disponíveis atualmente para redirecionar /proc e sysfs também cria uma base adequada para testes determinísticos.

Desenvolvimento de uma biblioteca mais modular

Conforme novas métricas forem adicionadas, a biblioteca poderá ser dividida em módulos especializados:

libcpu
│
├── cpu_info
├── cpu_usage
├── cpu_frequency
├── cpu_temperature
├── cpu_processes
├── cpu_topology
├── cpu_power
└── cpu_backend

A API pública continuaria funcionando como uma camada estável sobre esses componentes.

Essa organização reduz o impacto de novas funcionalidades sobre o código existente e facilita manutenção e testes.

Possível evolução da ferramenta

A longo prazo, o CPU Reader poderá deixar de ser apenas um leitor de CPU e se transformar em uma pequena infraestrutura de monitoramento de hardware.

Uma possível evolução seria:

                 CPU Reader
                     │
        ┌────────────┼────────────┐
        ↓            ↓            ↓
       CPU          RAM         Sistema
        │            │            │
     Uso/Clock    Memória      Processos
     Temp/Core    Swap         Load
        │            │            │
        └────────────┼────────────┘
                     ↓
              API de monitoramento
                     ↓
          ┌──────────┴──────────┐
          ↓                     ↓
    Terminal / CLI          Aplicações

Nesse cenário, a biblioteca poderia se tornar a camada de coleta de dados enquanto diferentes aplicações seriam responsáveis pela apresentação dessas informações.

Princípio fundamental

Mesmo com a expansão do projeto, o objetivo não é transformar o CPU Reader em uma biblioteca excessivamente complexa.

A direção desejada é:

pequena → modular → previsível → extensível → portável.

A biblioteca deve continuar próxima do sistema operacional, permitindo que o desenvolvedor compreenda de onde os dados vêm e como eles são transformados antes de chegar à aplicação.

Roadmap conceitual

A evolução pode ser organizada em etapas:

FASE 1
Leitura básica da CPU
        ↓
FASE 2
API estável + testes
        ↓
FASE 3
Monitoramento por núcleo
        ↓
FASE 4
Sensores e frequência
        ↓
FASE 5
Thread-safety e contextos
        ↓
FASE 6
Portabilidade
        ↓
FASE 7
Novas métricas do sistema
        ↓
FASE 8
Infraestrutura de monitoramento

Esse roadmap não representa necessariamente um cronograma de implementação. Ele representa a direção arquitetural possível para o projeto.

Conclusão

O futuro do CPU Reader está na evolução gradual de uma ferramenta experimental de leitura de CPU para uma biblioteca de monitoramento modular, confiável e extensível.

A prioridade deve permanecer na qualidade da base: uma API clara, gerenciamento correto de recursos, tratamento de erros, testes confiáveis e separação entre funcionalidades específicas do sistema e a interface pública.

A partir dessa base, novas métricas e novos backends podem ser adicionados sem comprometer a simplicidade original do projeto.