[Kos-dev] Re: [SOS] Kernel et modules.

[Thomas Petazzoni]

Salut,

[ Je poste en Cc: sur kos-dev, car le sujet concerne KOS ]

David MENTRE a écrit :

> Thomas et David me corrigeront mais je ne pense pas que la structure 
> modulaire de KOS permette de réduire la taille du noyau, que ce soit 
> en source ou en mémoire à l'exécution.

Effectivement, l'architecture modulaire de KOS ne change rien à la
taille du noyau. Une fois les modules "linkés" entre eux par le loader
au démarrage de l'OS, ils ressemblent comme deux gouttes d'eau à un OS
monolithique classique: tout s'exécute en espace noyau, et tout se passe
par appel de fonction direct.

La structure modulaire ne permet donc pas de réduire la taille du noyau,
mais de séparer les différentes fonctionnalités en des modules aux
interfaces clairement définies.

> À ce propos, je serais curieux de voir si Xavier a exploité de
> manière similaires les packages et/ou objets Ada pour structurer le
> code de son OS.

Xavier me corrigera si je me trompe, mais d'après les slides [1] de sa
présentation aux RMLLs, il utilise intensivement les «packages» Ada pour
structurer Toy Lovelace. (Voir page 6 des slides).

D'ailleurs, vous trouverez sur
http://medias.2005.rencontresmondiales.org/topics/os/ les papiers,
slides de quasiment toutes les conférences du thème OS des RMLLs de
cette année, ainsi que des enregistrements audio (de qualité discutable,
mais qui ont le mérite d'exister). David, tu trouveras en particulier le
papier sur Coyotos, l'OS qui se veut être formellement prouvable.

> Enfin, pour regarder vers le futur, il me semble qu'il faudrait aller
>  plus loin encore dans cette réflexion sur les modules, en incluant
> des spécifications et/ou contraintes sur les aspects dynamiques dans 
> l'utilisation des points d'entrée des modules. Par exemple, que tel 
> fonction peut être bloquante et mettre l'appelant en veille, ou que 
> telle fonction ne doit pas être appelée d'un handler d'interruption 
> avec un verrou pris. Ce serait à rapprocher de certaines idées 
> réalisées dans le projet SLAM de Microsoft Research : 
> http://research.microsoft.com/slam/

Pour l'instant, le mécanisme d'interfaçage entre les modules est très
bas-niveau: il ne repose que sur les symboles ELF, rien de plus. Il n'y
aucune vérification du typage, et encore moins de spécifications sur les
contraintes ou l'utilisation des fonctions comme tu le proposes. En
dehors du symbole en lui-même, la seule information qu'on a, c'est le
"scope" d'utilisation du symbole. Il y a quelques temps, j'ai en effet
committé quelque chose qui permet de restreindre l'accès d'un symbole
exporté à un seul module.

Parallèlement, il y a les interfaces niveau KARM, décrites en XML, qui
permet de générer des stubs serveur (noyau) et client (utilisateur).
L'aspect XML permet d'envisager à peu près n'importe quoi comme
spécifications sur les fonctions. Actuellement, on y détaille le typage
ainsi que l'accès (réservé au noyau ou disponible à l'utilisateur).

En fait, depuis quelques temps, quelque chose me gène dans KOS: ces deux
mécanismes d'interfaces, l'un très bas-niveau, l'autre beaucoup plus
haut niveau. On pourrait se dire qu'ils sont complètement indépendants
et orthogonaux, en se disant que KARM n'est utilisé que pour la
communication utilisateur/noyau. En réalité, KARM est également utilisé
au sein du noyau, par exemple pour qu'un système de fichiers lise un
périphérique bloc ou pour que le pilote de partitions disques lise un
disque dur. Les interfaces KARM viennent donc supplanter le mécanisme
d'import/export de symboles entre les modules: bien que le pilote IDE
n'exporte rien (ou quasiment), on utilise plein de ses fonctionnalités
au travers d'interfaces KARM.

Avec ces deux mécanismes d'interface, je trouve que la conception est
beaucoup moins jolie, et je me demande si une unification ne serait pas
souhaitable ? Mais comment ? Dans quel sens ?

(N'hésitez pas à demander des précisions sur ce point si ma prose n'est
pas compréhensible: c'est vraiment un point sur lequel j'aimerais
débattre et recueillir des avis).

David, merci pour ton lien vers SLAM, je vais regarder de plus près de
quoi ça parle.

Bonne soirée,

Thomas

[1]
http://medias.2005.rencontresmondiales.org/topics/os/slides/grave-toy-lovelace.pdf
-- 
PETAZZONI Thomas - thomas.petazzoni at enix.org
http://thomas.enix.org - Jabber: thomas.petazzoni at jabber.dk
KOS: http://kos.enix.org/ - SOS: http://sos.enix.org
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://the-doors.enix.org/pipermail/kos-dev/attachments/20050824/dd53c27d/signature.pgp