
Um exokernel moderno
Antes mesmo de falar sobre o sistema de construção escrito à mão, preciso mencionar o Esque.toml. Este é um arquivo de configuração com uma infinidade de opções disponíveis para personalização. A configuração disso levou muito tempo, e é por isso que agora é o padrão para a construção do ESQUE OS.
cargorustcddmtools (McOpy, MMD, ...)dosfstools (mkfs.vfat)python >= 3python.tomlpython.xbstrap$ sudo apt install cargo rustc binutils mtools dosfstools python3 python3-pip ; pip install --user xbstrap toml y.py é um utilitário inspirado no x.py da Rustc. Você pode configurar o kernel usando o arquivo Esque.toml que pode ser encontrado no sysroot deste diretório. Este arquivo oferece muitas opções, dê uma olhada antes de construir.
Você pode construir o projeto simplesmente usando
./y.py build
Este sistema é muito configurável. Simplesmente digite
./y.py --help
Para ver todas as opções.
Primeiro, você deve inserir Esque.toml e alteração enable-kvm para false.
Construir no Windows não é recomendado. Eu sou usuário de longa data do Linux e todo o processo de compilação foi projetado para mim, no entanto, a construção do winy.ps1 é possível, mas não otimizada.
No Windows, apenas alguns comandos y.py podem ser executados da mesma maneira que no Linux (exemplo: ./y.py Build executa dd para criar um arquivo IMG). Portanto, você recebe duas opções
Esta pode ser uma opção preferida para alguns. Nesse cenário, você executa todos os comandos, exceto ./y.py run usando o WSL.
Isso requer todas as dependências listadas acima na seção Dependencies (On Linux)
winy.ps1 é um script do PowerShell que decide o que correr nativamente e o que não. ./winy build uso é igual a ./y.py ./winy run exemplo
Atenção isso exige que você tenha sua execução de policia para ser desviado. Você pode alterar temporariamente isso abrindo um host de comando com privilégios de administrador e digitando
Set-ExecutionPolicy Bypass Isso requer todas as dependências listadas acima , exceto para carga e rustc no WSL. Requer carga, rustc e um binário tar nas janelas. As dependências referidas podem ser facilmente instaladas usando o Rustup Binário rustup.rs
Execute o seguinte comando no WSL (assume o Ubuntu):
$ sudo apt install binutils mtools dosfstools python3 python3-pip ; pip install --user xbstrap tomlUm sistema operacional deve estar perto de ser livre de dependência. Infelizmente, este sistema depende de um total de 2 caixas:
bitflags
spin
Mais de 10 de nossas próprias dependências são mantidas dentro das crates/ subdiretório. Essas dependências incluem um carregador de alcatrão e muito mais.
std::sync::{Mutex,...} . Esta é uma caixa incrivelmente útil que é usada em quase todos os principais projetos da OSDEV. Esta caixa pode ser descartada no futuro. Embora possa produzir binários maiores, digamos, C, ainda produz pequenos depois de se despir. O kernel atual tem apenas ~ 300k de tamanho, o que é aceitável para mim. O bootloader é cerca de 270k grande, devido à sua enorme dependência 'UEFI'.
O Esque é um kernel que procura unir aspectos do Linux e do Windows, enquanto é um sistema semelhante ao exokernel. Um exokernel é um kernel que fornece apenas as coisas básicas e quaisquer coisas adicionais (como pilhas de rede) são carregadas por meio de módulos.
Devido à enorme disponibilidade de software no Linux, o ESQUE visa ser um pouco compatível com ele. Ele atinge a compatibilidade do sistema de arquivos devido ao uso de uma fake-root . Existem dois principais. A raiz real e a raiz falsa . Um exemplo de um caminho falso seria /home/user/ ou /bin/* . Um caminho raiz real começa com o dispositivo: esquema de caminho . Exemplos: initramfs:/myfile , C:/Binaries/* , B:/BOOT/EFI/BOOTX64.EFI , C:/Users/User/ ou proc:/CpuInfo .
Os syscalls Linux estão localizados em sua localização real (0, 1, 2, 3, 4 ...) enquanto os syscalls ESQUE estão localizados em (sys_num + 0x1000)
Sim - e não. No ESCE, existem três 'espaços' virtuais diferentes para aplicações. Apenas dois deles são reais. Há
Entendo que muitos não estão dispostos a usar seu tempo em um kernel como este. Ainda vou dar as boas -vindas a qualquer contribuição, não importa quão grande ou pequena. Leia o arquivo de contribuições e dê uma olhada nos arquivos no diretório de documentação
Nos initramfs, a partir de agora, nenhum diretório é suportado. Você pode criar um novo initramfs simplesmente colocando arquivos no initramfs/ subdirectory. Em seguida, usando ./y.py initramfs o initramfs acabado será encontrado no build/initramfs.tar . O carregador de inicialização espera que esse arquivo seja encontrado na partição raiz.
Todos os arquivos que terminam com .system serão carregados pelos initramfs. Espera -se que um dos referidos arquivos .system carregue o sistema de arquivos.
Embora seja verdade que um sistema operacional sem código inseguro é impossível, tentei limitá -lo aqui. A qualquer momento,
./y.py count-unsafe
Pode ser chamado, que exibirá informações sobre a insegura do código. No momento da redação deste artigo, a seguinte saída é produzida:
A total of 52 occurences have been found (1641 LOC, 0.* percent Percent)
alloc