[SOS] Projet de développement d'OS

[David Decotigny]

Bonjour,

Grégoire wrote:
> Je vais me lancer dans un nouveau projet dénommé YoctOS.

Tiens tiens, c'est une démarche qui rappelle des souvenirs ;)

Bon vent a YoctOS !

> D'ailleur quelqu'un peut-il me convaincre des avantages de 
> l'architecture modulaire de KOS et me dire si les performances sont aux 
> rendez-vous car je reste quand même un peut ceptique ?

Il y a plusieurs points originaux dans Kos. L'aspect modulaire en est
effectivement un pour plusieurs raisons.

C'est un mecanisme tres proche de ce qui se passe dans Linux, juste
poussé un peu plus loin. Dans Kos comme dans Linux, le noyau peut être
formé de "modules". Ces modules sont de simples fichiers ".o" et il
s'agit de faire l'édition de liens pour les intégrer dans le reste du
noyau. L'édition de liens est faite en entier une fois pour toute, à la
différence de l'édition de liens dite "dynamique" qui est faite
progressivement, à la demande, en fonction des appels de fonctions et
des références aux variables (les fichiers .so et le fameux ld.so). Une
fois l'édition de liens faite, les appels de fonctions et les références
aux variables se font absolument sans aucun surcoût à l'exécution. Car
on a fait ni plus ni moins qu'une édition de liens statique normale.

Dans Linux, il y a un noyau de base qui est monolithique, le reste peut
se greffer sous forme de modules. Dans Kos, même le noyau de base est
constitué de modules. Par exemple il y a un module pour la gestion de la
mémoire physique séparé du module de config de la MMU. Impossible sous
Linux. Pour que ça fonctionne, nous avons développé un mini-nano-noyau
dont le rôle est de faire l'édition de liens pour le noyau de base avant
le lancement du noyau. S'il y a un surcoût, il se trouve donc au
chargement du noyau mais pas après. Et ce surcoût est ridiculement
petit, inférieur à 1s.

S'il y a une originalité de Kos pour ce qui concerne sa modularité,
c'est au niveau de ce mini-nano-noyau, le "loader", qu'elle se trouve.
D'ailleurs, pour qui veut se lancer dans un noyau modulaire, il peut
très bien reprendre ce loader sans reprendre du tout le reste de Kos. Ca
permet de partir très vite sur un noyau modulaire sans s'encombrer des
histiores de scripts ld & co : il suffit de savoir faire "gcc -c
fichier.c" et c'est regle, le loader s'occupe du reste.

L'autre point original de Kos est la gestion uniforme des "ressources"
telles que les peripheriques, les repertoires, les fichiers. Parc
exemple, dans Unix, quand vous changez le volume de votre carte son, la
résolution de votre écran, etc. ça se fait en utilisant les fichiers
spéciaux /dev/toto. Mais comme le VFS de base 1/ ne connait que tres peu
de types de ressources (fichiers, repertoires, liens soft, fifo,
sockets, ipc sysv, periph bloc/car) et 2/ ne propose pas l'opération
"change_volume" par exemple, il vous faut utiliser un "ioctl". Il s'agit
d'une operation du VFS "foure-tout" a laquelle ou fournit un identifiant
dépendant du driver et des données associées. C'est le driver qui décide
comment interpréter l'identifiant et quoi faire avec les donnees. Donc
c'est loin d'être standardisé, des drivers analogues risquent d'utiliser
des identifiants differents pour faire la meme chose, et ça fait véru.

Dans Kos, on dispose d'un système où les interfaces de contrôle des
ressources peuvent être aribtraires : on peut avoir une méthode
change_volume si on veut, il suffit que la ressource "instancie"
l'"interface" "CARTE_SON". La définition de ces interface se fait en XML
et on génére des stubs du cote noyau et du cote user pour que les applis
utilisateur puissent appeler ces services du noyau sans surcoût (ce ne
sont pas des RPC façon micro-noyau). Tout cela s'integre parfaitement
avec les modeles de VFS Unix classiques. Par exemple, les interfaces de
ressources classiques fichiers (read/write/seek) et repertoires
(readlink, readdir, etc.) sont decrites par des fichiers XML.

Thomas, quels autres points originaux ai-je oublié ?

Bonne journee,

-- 
David Decotigny -- http://david.decotigny.free.fr