Chengcheng OS (CCOS) est un système d'exploitation hobby 64 bits. Je l'écris sur x86, parce que j'aime la tristesse et la misère. Ce projet était toujours en développement. Je suis un débutant pour la conception du système d'exploitation. De nombreux concepts de conception que j'ai mis en œuvre sont inspirés par Windows NT tels que CCLDR (OS Loder pour Chengcheng OS) et Memory Manager. Et, il y a beaucoup plus de cours que je dois apprendre pendant les mois à venir. Donc, je ne mettrai pas à jour le projet fréquemment.

Uefi
CCOS utilise UEFI pour bootstrap ccoskrnl. L'UEEFI facilite considérablement le développement du chargeur de système d'exploitation. Le développeur peut appeler directement les interfaces fournies par UEFI (utilisez le langage C au lieu de l'assemblage). Il y a une chose à noter ici que CCOS a encore besoin de CCLDR (un autre fichier exécutable binaire) pour charger CCOSKRNL. C'est un peu comme "un chargeur de démarrage en deuxième étage". Mais en fait, BOOTX64.EFI divise simplement l'espace du noyau et recherche un espace mémoire physique approprié pour le chargement de l'image CCOSKRNL. Ensuite, CCLDR mappera l'espace du noyau dans une adresse élevée de l'espace d'adressage virtuel et définira GDT (Tableau des descripteurs global, une structure significative pour l'architecture x86.)
Multi-processeurs
Le support multiprocesseurs est un énorme défi pour moi. Je ne garantis pas une bonne implémentation du système multi-processeurs. Pour l'instant, le CCOS peut correctement actif d'autres processeurs d'applications. Pas comme les autres démo du système d'exploitation, CCOS met la routine d'initialisation du processeur d'application dans un fichier binaire isolé et le charge dans le premier MIB de la mémoire physique et construisez séparément le tableau de page pour l'espace mémoire. Avant les processeurs d'application en cours d'exécution, CCOS fixera la citation de l'adresse relative du programme binaire. Je dois admettre que c'est un design stupide.
Apic
APIC (Advanced Programmable Interrupt Controller) est un composant critique dans le système informatique moderne. Il offre la possibilité du système multiprocesseurs et prend en charge la priorité d'interruption à plusieurs niveaux au niveau matériel. Malheureusement, APIC est compliqué. Puisque pour bien comprendre APIC a besoin d'une connaissance solide du système informatique, je n'implémente que le moteur de base de l'APIC.
Trueype
CCOS affiche les caractères à l'écran via des polices de truetype de rendu (police par défaut dans CCOS est Adobe Source Han Sans Sc VF ). Il ne vaut pas la peine de produire des caractères en utilisant le rendu TrueType. Pour le développement précoce du système d'exploitation, l'utilisation de la police bitmap est une méthode plus recommandée de sortie de caractères.
La plus grande chose à propos de stocker des personnages comme contours est probablement qu'un seul contour par personnage est nécessaire pour produire toutes les tailles de ce personnage que le système d'exploitation aura besoin. Un plan unique peut être mis à l'échelle à une énorme gamme de différentes tailles, dont certaines sont illustrées ci-dessous. Cela permet d'afficher le même caractère sur des moniteurs de différentes résolutions et à imprimer à un grand nombre de tailles différentes. Pour évoluer un contour de caractère est une simple opération mathématique, tout comme d'autres transformations telles que la rotation et les réflexions.
La structure de TrueType est complexe, je n'ai implémenté que le rasterizer de police sans allusion à TrueType. L'arrière est au cœur de TrueType. Ses inventeurs, conscients de la diversité d'opinion sur la manière "correcte" de faire allusion, ont décidé qu'il n'y avait pas de paradigme d'information unique qu'ils imposeraient aux développeurs de type. Au lieu de cela, ils ont lié un rasterizer relativement simple à un nouveau langage de programmation interprété. Pour la lisibilité des polices, cependant, cela suffit.
Il s'agit d'un Issus cirtique ici, c'est-à-dire que la préformation de la sortie du texte des CCO est très pool. Le mal performant ralentira sérieusement le fonctionnement des CCO. Je ne sais pas comment optimiser la fonction car le dessin de police est un processus relativement complexe. Une autre méthode consiste à utiliser la police bitmap pour plutôt la police TrueType.
Charbon
CCOS propose deux types de caractères, "char" et "wch_t" (large char, 4 octets), pour stocker tous les caractères. Quel que soit le type de caractère, CCOS convertit toujours WCH_T d'abord, puis publie une large chaîne. En fait, l'analyseur TrueType dans les CCO n'utilise que "Unicode 2.0 et Sémantique vers la fin", quelle plate-forme ID = 0 et codage ID = 3 dans CMAP (CMAP - Tableau de mappage du caractère à l'indice des glyphes, une struture dans TrueType.). Par conséquent, il prend en charge exclusivement les caractères de plan multilingue de base Unicode (U + 0000 à U + FFFF).
Gestionnaire de mémoire
Les idées de conception de la gestion de la mémoire s'inspirent de la fenêtre NT, qui contient une base de données PFN, un apparence, un schéma de mappage auto-répertoire, une gestion de pool de mémoire de laminage, mais pas à tous.
Sortie graphique avec plusieurs aidons
Le CCOS prend en charge les multi-fenêtres, ce qui signifie qu'il peut sortir du texte dans une fenêtre différente à l'écran. Il est utile de déboguer les multi-processeurs en ouvrir une fenêtre de sortie de texte à chaque processeur. Même s'il n'a pas de pilote de souris, l'utilisateur peut également utiliser le clavier pour sélectionner la fenêtre nécessaire pour saisir les caractères.
Correction de bug: ajouter Spinlock pour éviter les conflits de sortie de plusieurs fenêtres
Gestionnaire de mémoire dynamique avec détection de fuites de mémoire
Gestion du Système en TP
Gestion de PCIE
Pilote NVME
Conducteur de clavier (non urgent)
Qemu avec 2 gib RAM ou plus
Je divise à peu près l'espace mémoire de telle sorte que l'espace du noyau n'utilise le quart de la RAM de la disponibilité. Mais un problème doit remarquer que la routine getMemoryMap () a renvoyé les informations de carte mémoire incorrectes lors de la tentative d'attribution de RAM plus élevée (plus de 2 GIB) pour Qemu. Je n'essaye pas d'autres firmwares OVMF, donc je suppose qu'une telle erreur peut provenir de mon OVMF.
x86_64 CPU (Intel ou AMD) avec ensemble d'instructions AVX
Il existe de légères différences sur la programmation d'architecture x86_64 entre Intel 64 et AMD64. Je développe des CCO basés sur le processeur AMD mais j'utilise les manuels du développeur du logiciel Intel® 64 et IA-32 comme manuel de référence architechure x86_64. Pour l'instant, cependant, quel que soit le fournisseur du processeur.
Pour l'installation, veuillez vous référer à la construction CCOSKRNL
La bibliothèque mathématique (Reflibs / libm.a) a été fournie par @estrella
Pas de licence.
E-mail: [email protected]
Chengcheng OS: https://github.com/ccoskrnl/ccoskrnl
Manuels du développeur de logiciels Intel® 64 et IA-32 Architectures
AMD64 Architecture Programmer's Manual Volume 2: Programmation système
Le langage de programmation C
Osdev Wiki
Spécification ACPI
Spécification UEFI