[Français] [English]

Caractéristiques

Le système d'exploitation KOS présente deux caractéristiques particulières qui le distingue des autres systèmes d'exploitation. Elles existent dans d'autres systèmes d'exploitation expérimentaux, mais ne sont pas classiques, et présentent donc un intérêt.

• Conception modulaire : le noyau de KOS est découpé en différents modules, chargés par GNU Grub et linkés au démarrage par un loader spécifique. Contrairement à Linux où seuls des pilotes de périphériques ou des parties optionnelles du noyau peuvent être placées en modules, l'ensemble du noyau de KOS est composé de modules, jusqu'au scheduler ou à la gestion de la mémoire virtuelle. Cela présente de nombreux avantages, notamment en ce qui concerne la séparation claire des fonctionnalités du système. Les modules sont donc des fichiers objets au format ELF chargés depuis le disque ou via le réseau par Grub. Notre loader effectue ensuite l'édition de liens sur les modules et lance le programme résultant : le noyau. La première phase du lancement consiste à le système dans l'ordre des init levels de chaque module. Pour plus d'informations sur les modules, vous pouvez vous reporter à la documentation Modules dans KOS, au format HTML, PostScript ou PDF ;
• Gestion des ressources système : Collecteur d'interfaces appelé Karm, pour Kos Abstract Resource Management. Karm se charge du lien entre l'utilisateur et le noyau. L'objectif est de remplacer la rigidité de l'interface unique fichier à la Unix et la pseudo-souplesse des ioctl() par un système permettant d'exporter vers les applications et bibliothèques utilisateur des interfaces spécialisées. Chaque ressource du système peut alors être accédée par un jeu d'interfaces spécifiques à cette ressource, qui dépendent de sa nature. Pour plus d'informations, vous pouvez vous reporter au rapport rédigé par Mélanie Bats et Thomas Petazzoni lors de leur travail sur ce sujet à l'UTBM, au format PDF ;

En plus de ces fonctionnalités un peu originales, KOS possède actuellement les caractéristiques suivantes :

• Architecture cible : PC, processeurs de la famille Intel 80486 ou Pentium. Uniprocesseur pour le moment.
• Machine hôte : chaîne de compilation GNU C (gcc, binutils, ...), format objet ELF32. Unix (Linux/x86, Solaris/sparc+cross-gcc Ok) fortement recommandé
• Adressage mémoire physique :par pagination essentiellement (segmentation configurée en mode Flat). 4Go adressables sans restriction (le noyau ne repose pas sur l'identity mapping). Extension PAE à terme (pour adresser 64Go).
• Noyau :
  • monolithique constitué de modules ELF liés en run-time
  • multithreadé, préemptible, réentrant
  • conçu pour le SMP (Symetric Multiprocessing)
  • primitives de synchronisation noyau : spinlocks, mutex, message queues, sémaphores, waitqueues
  • gestion des interruptions type bottom-half handlers ("DSR") et tasklets ("DST")
  • ordonnancement: round-robin de base pour le moment (remplacé par autre chose à terme)
  • isolement niveau source des parties portables/non portables
• Gestion mémoire physique (module arch/mm) :
  • utilisation du reverse mapping pour faciliter le swapping ("rmap")
  • Possibilité de déplacer n'importe quelle page de la mémoire physique ("vmap")
• Allocation dans l'espace d'adressage noyau (0-2Go) : allocateur type 'slab' (module kmem)
• Gestion espaces d'adressages : modèle objet VM de SVR4 (module vmm). Demand-paging, anonymous et file mapping
• Mode utilisateur : Plusieurs teams existent, chacun(e) définissant un espace d'adressage, et constitué(e)s de threads. Les teams peuvent partager des pages en mémoire. L'espace noyau (0-2G) est partagé par tou(te)s les teams. Premieres applications utilisateur de test avec une minuscule libc qui permet d'accéder aux ressources et aux interfaces exportées via le système Karm dont il a été question ci-dessus.
• Ressources systèmes et matérielles :
  • Driver console simpliste
  • Driver clavier simpliste
  • Driver ATA, détection et lecture des disques durs
  • Driver part, pour la lecture des table de partition
  • Driver FAT, pour la lecture uniquement
  • Driver ligne série ultra-minimal pour le Debug
  • Début de driver PCI
• Debug : Sortie sur ligne série et en utilisant le port-e9-hack de Bochs. Fonctionnalités intégrées: désassembleur x86, backtrace, lookup des noms de fonctions.
• Divers : Bibliothèques de gestion de structures de données libbst (splay trees), liblist (macros pour la gestion de listes circulaires doublement chaînées) et libhash (tables de hachage).