NeptuneOS
v0.2.0002
Neptune OS est une personnalité Windows NT pour le microkernel Sel4. Il met en œuvre ce que Microsoft appelle le "NT Executive", la couche supérieure du noyau Windows NTOSKRNL.EXE , en tant que processus utilisateur sous le microkernel SEL4. L'exécutif NT implémente la soi-disant API native NT, l'interface d'appel système native de Windows sur laquelle est construit l'API Win32 plus familière. Ceux-ci sont exposés au mode utilisateur via des fonctions Stub dans NTDLL.DLL avec des noms tels que NtCreateProcess . L'exécutif NT est également chargé d'exposer une interface de programmation aux pilotes d'appareil. Cette interface comprend des fonctions comme IoConnectInterrupt et IoCallDriver . Notre architecture permet aux pilotes de périphériques d'exécuter dans des processus d'espace utilisateur séparés et de communiquer avec le processus exécutif NT via des primitives standard de SEL4 IPC.
L'objectif éventuel du projet Neptune OS est de mettre en œuvre suffisamment de sémantique NT de telle sorte qu'un terrain utilisateur Reactos puisse être porté sous le système d'exploitation Neptune, ainsi que la plupart des pilotes de noyau Reactos. En théorie, nous devrions être en mesure d'atteindre la compatibilité binaire avec les exécutables de Windows natifs à condition que notre implémentation de l'API native NT soit suffisamment fidèle. Nous devrions également être en mesure d'atteindre un degré élevé de portabilité du code source avec les pilotes de périphérique Windows et les pilotes du système de fichiers, bien que nous ne visions pas la compatibilité complète du code source à ligne en ligne en raison des différences architecturales avec Windows / Reactos qui rendent cet objectif non réaliste. Veuillez consulter la section Documentation pour plus d'informations.
L'état actuel du projet est que nous avons mis en œuvre suffisamment de composants exécutifs NT pour prendre en charge une pile de systèmes de fichiers raisonnablement complète avec la prise en charge de la lecture et de la mise en cache d'écriture, qui inclut le pilote FAT12 / 16/32 fatfs.sys et un pilote de contrôleur de floque fdc.sys . Nous avons également une pile de pilote de clavier de base, qui inclut le pilote de classe de clavier kbdclass.sys et le pilote de port PS / 2 i8042prt.sys . Ceux-ci nous permettent d'exécuter une invite de commande de base ntcmd.exe , tirée du projet Reactos, qui prend en charge la plupart des commandes de shell courantes, telles que pwd , cd , copy , move , del , mount et umount . Nous incluons également un pilote beep.sys qui fait un son ennuyeux sur le haut-parleur PC.
L'ensemble du système s'inscrit dans une disquette et peut être téléchargé à partir de la version V0.2.0002. Vous pouvez regarder une courte démo sur YouTube. Vous pouvez également le construire vous-même. Voir la section sur le bâtiment.
Pour la prochaine version, nous prévoyons de porter la pile de pilotes ATA / AHCI de Reactos afin que nous puissions prendre en charge la plupart des disques durs PATA / SATA. Nous prévoyons également d'écrire / de porter une suite de référence en disque afin que nous puissions démontrer qu'une conception de micro-nés ne conduit pas à des pénalités de performance inacceptables.
Pour les systèmes i386 (devrait probablement être appelé i686):
enable_paging dans sel4/src/arch/x86/32/head.S ).Pour les systèmes AMD64:
fsgsbase activée. Ceci n'est pris en charge que sur Ivy Bridge et plus tard. Pour exécuter AMD64 s'appuie sur des processeurs antérieurs, vous pouvez désactiver l'instruction FSGSBase dans private/ntos/cmake/sel4.cmake . Nous avons également besoin de CMPXCHG16B, qui est disponible depuis Nehalem, et très probablement plus tôt (les processeurs Core 2 antérieurs pourraient avoir besoin d'une mise à jour de microcode). Pour les machines amd64 , ThinkPad X230 a été testé pour fonctionner.
Vous devrez construire sous Linux (Sel4 ne construit pas dans un autre système d'exploitation). Vous aurez besoin des dépendances Python suivantes, et probablement plus.
jinja2
future
ply
setuptools
six
lxml
Vous aurez également besoin cmake , clang , llvm et lld en tant que chaîne d'outils de base. clang est un compilateur croisé natif qui peut générer des cibles ELF et PE. Le CCG n'est pas soutenu mais en théorie peut être fait pour fonctionner. Vous aurez besoin à la fois d'une chaîne d'outils Elf et d'une chaîne d'outils PE (et probablement une tonne de patience) si vous voulez faire fonctionner GCC. Vous avez également besoin du windmc qui est le compilateur de ressources de message PE de mingw . Jetez un œil à build.sh pour le script de construction. La version Clang préférée est de 15 mais les versions récentes devraient tout fonctionner. Vous avez également besoin de l'utilitaire cpio pour construire l'initcpio. Enfin, pour la disquette de démarrage et le démarrage ISO, vous aurez besoin des outils suivants: syslinux (pour Boot Floppy), grub et xorriso (pour Boot ISO) et mtools (pour les deux).
Il est recommandé d'utiliser un IDE compatible avec serveur de langue pour parcourir le code source. La configuration testée est le package lsp-mode sur emacs avec clangd comme serveur de langue. Le script build.sh générera le fichier compile_commands.json pour clangd . Vous devrez installer JQ à cet effet.
Clone le projet d'abord (assurez-vous d'utiliser git clone --recurse-submodules car nous incluons le noyau Sel4 en tant que sous-module), puis exécutez
./build.sh [amd64] [release]
Si vous ne spécifiez pas amd64 , c'est une construction i686 . Si vous ne spécifiez pas release , c'est une construction de débogage. Pour créer des floppies de démarrage, tapez
./mkfloopy.sh [amd64] [release]
Pour créer des isos de démarrage, tapez
./mkiso.sh [amd64] [release]
Pour simuler à l'aide de Qemu, exécutez
./run.sh [direct|iso|uefi] [amd64] [release] [extra-qemu-args]
Si vous spécifiez direct , alors Qemu chargera directement le noyau Sel4 et l'image NTOS (utilisant -kernel et -initrd ). Si vous spécifiez iso ou uefi , il chargera le démarrage ISO construit par mkiso.sh . L'option uefi configurera également QEMU pour charger le firmware UEFI, qui fournit une belle console FrameBuffer haute définition. Sinon, la disquette de démarrage créée par mkfloppy.sh est utilisée. Des arguments supplémentaires sont transmis à Qemu. Par exemple, pour exécuter la version de version i386 avec un haut-parleur PC activé dans QEMU, vous pouvez passer ce qui suit (cela suppose que vous utilisez une version Qemu récente et que vous avez PulseAudio)
./run.sh release -machine pcspk-audiodev=snd0 -audiodev pa,id=snd0
La construction de débogage peut fonctionner lentement, surtout si vous activez la journalisation du port série. Vous pouvez désactiver la journalisation en modifiant l'en-tête maître du projet Executive NT (voir private/ntos/inc/ntos.h ).
Nous utilisons la chaîne d'outils LLVM, donc la compilation croisée en théorie devrait simplement fonctionner sans manipulation spéciale. En pratique, sur i386 / amd64 le script de linker pour l'exécutable final Sel4 du noyau s'appuie sur des fonctionnalités que seuls les prises en liaison GNU LD, nous ne pouvons donc pas utiliser le LLVM Linker (LLD) pour lier le noyau Sel4. Cela signifie que vous aurez besoin des liaisons croisées GNU LD pour les Triples i686-pc-linux-gnu et x86_64-pc-linux-gnu installés à l'endroit habituel ( /usr/bin ) afin que clang puisse les trouver et les invoquer correctement lors de la liaison du noyau Sel4. La partie PE de la chaîne d'outils est complètement autonome et ne nécessite aucune manipulation spéciale lors de la compilation croisée (c'est déjà un chain croisé car nous ciblons des fenêtres sur un hôte Linux).
La compilation croisée est testée sur Archlinux fonctionnant sur Loongarch64 (processeur Loongson 3A5000) avec llvm-14 et semble générer le code correct. Veuillez ouvrir un problème si vous rencontrez un problème.
Notez que si votre grub est conçu pour la plate-forme native plutôt que pour i686 / amd64, l'ISO de démarrage généré par mkiso.sh ne fonctionnera pas car grub-mkrescue essaiera de copier les fichiers de démarrage de la plate-forme native sur l'ISO. Pour résoudre ce problème, renforcez le package GRUB pour i686 / amd64 (ou exécutez simplement la génération ISO finale sur un système i686 / AMD64).
Les documentations sont situées dans le répertoire docs . Pour les développeurs et ceux qui souhaitent comprendre le fonctionnement intérieur du système d'exploitation Neptune, lisez le Developer-Guide.md qui commence par un aperçu architectural du système d'exploitation et procède à l'explication des différentes décisions de conception des composants individuels du système d'exploitation. Il contient également le guide de portage du conducteur pour les personnes intéressées par le portage des pilotes de Reactos.
