esque
1.0.0
Un exokernel moderne
Avant même de parler du système de construction rédigé à la main, je dois mentionner Esque.toml. Il s'agit d'un fichier de configuration avec une pléthore d'options disponibles pour la personnalisation. La configuration de cela a pris beaucoup de temps, c'est pourquoi c'est maintenant la norme pour construire le système d'exploitation Esque.
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 est un utilitaire inspiré de Rustc's x.py Vous pouvez configurer le noyau à l'aide du fichier Esque.toml qui peut être trouvé dans le système système de ce répertoire. Ce fichier offre de nombreuses options, jetez un coup d'œil avant la construction.
Vous pouvez construire le projet simplement en utilisant
./y.py build
Ce système est très configurable. Tapez simplement
./y.py --help
pour voir toutes les options.
Tout d'abord, vous devez saisir Esque.toml et modifier enable-kvm en false.
La construction sur Windows n'est pas recommandée. Je suis un utilisateur de longue date de Linux et l'ensemble du processus de construction est conçu pour moi, cependant, la construction à l'aide de winy.ps1 est possible, mais non optimisée.
Sur Windows, seules certaines commandes y.py peuvent être exécutées de la même manière que sur Linux (exemple: ./y.py build exécute dd pour créer un fichier IMG). Par conséquent, on vous présente deux options
Cela peut être une option préférée pour certains. Dans ce scénario, vous exécutez toutes les commandes, sauf pour ./y.py run à l'aide de WSL.
Cela nécessite toutes les dépendances énumérées ci-dessus dans la section Dependencies (On Linux)
winy.ps1 est un script PowerShell qui décide quoi exécuter nativement et quoi non. L'utilisation est égale à ./y.py Eg ./winy run exécute le noyau et ./winy build build certaines parties du noyau en utilisant WSL et d'autres nativement.
Attention, cela vous oblige à faire en sorte que votre entreprise d'exécution soit contournée. Vous pouvez modifier temporairement cela en ouvrant un hôte de commande avec les privilèges de l'administrateur et en tapant
Set-ExecutionPolicy Bypass Cela nécessite toutes les dépendances énumérées ci-dessus, sauf pour la cargaison et RustC sur WSL. Il nécessite du fret, Rustc et un binaire tar sur les fenêtres. Lesdites dépendances peuvent facilement être installées à l'aide du rustup binaire rustup.rs
Exécutez la commande suivante sur WSL (suppose Ubuntu):
$ sudo apt install binutils mtools dosfstools python3 python3-pip ; pip install --user xbstrap tomlUn système d'exploitation doit être proche de la dépendance. Malheureusement, ce système dépend d'un total de 2 caisses:
bitflags
spin
Plus de 10+ de nos propres dépendances sont maintenues dans les crates/ sous-répertoire. Ces dépendances incluent un chargeur de goudron et bien plus encore.
std::sync::{Mutex,...} Rust. Il s'agit d'une caisse incroyablement utile qui est utilisée dans presque tous les principaux projets OSDEV. Cette caisse pourrait être abandonnée à l'avenir. Bien qu'il puisse produire des binaires plus gros, disons, C, il en produit toujours de petits après le déshabillage. Le noyau actuel n'a que d'environ 300 000, ce qui est acceptable pour moi. Le chargeur de démarrage est d'environ 270k gros, en raison de sa énorme dépendance «UEFI».
Esque est un noyau qui cherche à unir des aspects de Linux et de Windows, tout en étant un système de type Exokernel. Un exokernel est un noyau qui ne fournit que les choses de base et toutes les choses supplémentaires (telles que les piles de réseau) sont chargées via des modules.
En raison de l'énorme disponibilité de logiciels sur Linux, Esque vise à être quelque peu compatible avec elle. Il réalise la compatibilité du système de fichiers en raison de l'utilisation d'une fake-root . Il y a deux majeures. La vraie racine et la fausse racine . Un exemple de faux chemin serait /home/user/ ou /bin/* . Un vrai chemin racine commence par le schéma de dispositif: chemin . Exemples: initramfs:/myfile , C:/Binaries/* , B:/BOOT/EFI/BOOTX64.EFI , C:/Users/User/ ou proc:/CpuInfo .
Les systèmes Linux sont situés à leur emplacement réel (0, 1, 2, 3, 4 ...) tandis que les systèmes Esque sont situés à (SYS_NUM + 0X1000)
Oui - et non. Dans Esque, il existe trois «espaces» virtuels différents pour les applications. Seuls deux d'entre eux sont réels. Il y a
Je comprends que peu de gens sont prêts à utiliser leur temps sur un noyau comme celui-ci. Je serai toujours heureux de bien saluer toute contribution, peu importe la taille ou la taille. Veuillez lire le fichier des contributions et jeter un œil aux fichiers dans le répertoire de la documentation
Dans les initRamfs, à l'heure actuelle, aucun répertoire n'est pris en charge. Vous pouvez créer un nouveau InitRAMFS simplement en mettant des fichiers dans le sous-répertoire initramfs/ . Ensuite, en utilisant ./y.py initramfs l'initramfs fini sera trouvé dans build/initramfs.tar . Le chargeur de démarrage s'attend à ce que ce fichier soit trouvé sur la partition racine.
Tous les fichiers se terminant par .system seront ensuite chargés par les InitRAMFS. On s'attend à ce que l'un desdits fichiers .system charge le système de fichiers.
S'il est vrai qu'un système d'exploitation sans code dangereux est impossible, j'ai essayé de le limiter ici. À tout moment,
./y.py count-unsafe
peut être invoqué qui affichera des informations sur la dangereuse du code. Au moment de la rédaction du moment de la rédaction, la sortie suivante est produite:
A total of 52 occurences have been found (1641 LOC, 0.* percent Percent)
alloc 
