FoxTechWorld

FKernel

Table of Contents

Introdução

OSDev é um acrônimo para Operating System Development ou Desenvolvimento de Sistema Operacional, e isso é uma base importante do que pretendo fazer futuramente. O desenvolvimento de um Kernel moderno para a arquitetura x86 64 em C++.

A ideia é que o kernel tenha algumas licenças para permitir que o código seja atualizável como a GPL com um pouco mais de tranquilidade como a licença do MIT.

Com uma incrível capacidade de adaptação como o MINIX / MACH sem desgastar muito o desempenho do sistema operacional usando o modelo de um kernel híbrido

Quais seriam os diferencias do FKernel em comparação com outros kerneis

Driver Interface

// Enum para representar o estado do driver
enum class DriverStatus {
    OK,
    Error,
    // Adicione outros estados conforme necessário
};

// Interface virtual para o driver
class DriverInterface {
public:
    virtual DriverStatus initDriver() = 0;
    virtual DriverStatus readData(uint8_t* buffer, size_t size) = 0;
    virtual DriverStatus writeData(const uint8_t* buffer, size_t size) = 0;
    virtual void shutdownDriver() = 0;
    virtual ~DriverInterface() = default;

    // Adicione métodos adicionais conforme necessário, por exemplo:
    virtual DriverStatus resetDriver() = 0;
    virtual DriverStatus setConfiguration(const void* config, size_t configSize) = 0;
    // ...

    // Adicione métodos getters para informações do driver, por exemplo:
    virtual String getDriverName() const = 0;
    virtual String getDriverVersion() const = 0;
    // ...
};

Filesystem Interface

enum class FileStatus {
    Opened,
    Closed
    // ...
};

class FileSystemInterface {
public:
    virtual ~FileSystemInterface() = default;

    // Operações comuns do sistema de arquivos
    virtual void open(const std::string& filename) = 0;
    virtual void close() = 0;
    virtual size_t read(void* buffer, size_t size) = 0;
    virtual size_t write(const void* buffer, size_t size) = 0;

    // Métodos de acesso
    virtual FileStatus getStatus() const = 0;
    virtual std::string getFileName() const = 0;

    // Tratamento de erros
    virtual bool isError() const = 0;
    virtual String getErrorDescription() const = 0;
};

Podemos dizer que esses Kits vão precisar ser rapidamente atualizados e reescritos em breve, para poderem ser parsear structs de C entre outras funções para aumentar compatibilidade.

Alguns recursos monoliticamente instalados do FKernel

Hypervisors Monoliticamente instalados no FKernel

Formatos de Arquivos Monoliticamente instalados no FKernel

Sistema de Arquivos Monoliticamente instalados do FKernel

Está é uma categoria que eu chamo de sistemas de arquivos **Reais,ou seja,a está literalmente trabalhando com seus arquivos, mas tem uma subcategoria chamada sistemas de arquivos Virtuais ou **Falsos**.

Aqui é escusado explicar em detalhes, mas deixo uma visão geral. Da mesma forma que alguns sistemas de arquivos trabalham em armazenamento de dados, outros funcionam mostrando seus dados em arquivos virtuais aka SysFS, DevFS, TmpFS. Eles também serão inclusos no FKernel junto de outros sistemas como 9p, SSHFS, UnionFS, *OverlayFS… De forma monolítica

Atraindo pessoas para o FKernel

Claro que não pretendo deixar apenas isso no Kernel, sua expansibilidade permite adicione novos formatos, drivers, dispositivos… Contanto que a versão default não seja alterado, ou seja, além do que já temos.

No momento, o FKernel está em fase de planejamento, mas esses são alguns recursos-base que pretendo adicionar ao FKernel, com algumas optimizações de C++ em suas instruções que seriam sobrecarregadas por versões otimizadas utilizando SIMD em instruções acessíveis ao limite do SIMD que é maior que 8 ou maior que 16.

Uma coisa que posso dizer é que o código vai ter um HIG para melhor desenvolvimento do Kernel seguindo algumas boas práticas da programação:

Claro que seria bastante chato para convencer novas pessoas a pelo menos testarem o FKernel, então penso que uma boa solução seria criar um montador de distros como o SUSE Studio usando Dialog + Shell Script + Xmake que possa ser usado tanto para Linux quanto para FKernel, dessa forma atraímos pela utilidade e mantemos pela curiosidade do que seria FKernel.

Outra boa forma seria aprofundar o FKernel num OS, próprio mais customizado para ser direto ao ponto com suporte a DRI, HDI, … Entre outros usando a estrutura aberta e permitindo a fechada de forma facilitada.

Conclusão

No fim de toda essa explicação, podemos dizer que o código do FKernel deve ser preparado para ser legível, modular, com diversas capacidades para melhorar seu desenvolvimento e execução em runtime.

Valendo-se de recursos como containers, virtualização, para virtualização, módulos de Kernel com VFS, DriverKit, Jails… Entre outros para garantir o melhor desempenho em comparação com outros Kerneis.

comments powered by Disqus
Tags: