[Kos-dev] Abstraction a la base de KOS ?

Thomas Petazzoni kos-dev@enix.org
Wed, 11 Jul 2001 15:20:13 +0200


> "Rien" d'accord, mais ce "rien" n'est pas "vide". "Rien", ok si ca
> veut dire "pas de methode liee au peripherique qu'il y a derriere"
> (pas de read/write/...). Par contre, ce "rien", que j'appellerais bien
> "root_interface", ca serait bien qu'il ait des mecanismes
> d'introspection : get_name(), quel type, quelles methodes dans son
> interface, quelle version...

oui bien sur, quand je dis rien, c'est plutot rien de specifique, les
trucs de bases, vraiment communs a toutes les interfaces.

> C'est ca qu'il reste a determiner  la root_class.

bin personnellement je pense que sur ce point la, et sur tous les
autres, il ne faut pas oublier notre methode de programmation : on the
fly.
On a deja pas mal reflechit a ce qu'il y allait avoir dedans, eh ben
maintenant codons le, et apres on verra si il manque des choses, etc...

> D'ou la necessite, pour mener a bien l'introspection, d'avoir 2 types
> d'objets : les interfaces (root_interface en est une), et les instances
> derriere. Je me souviens plus comment Babel est constitue, mais ca
> doit etre qqch comme ca.

Effectivement c'est ainsi que Babel est construit si j'ai bien compris.

> Mais cet espace de nommage a ses
> limites. Pour preuve la decorrelation totale de la gestion reseau et
> des IPC SysV par rapport au systeme de fichiers.

effectivement

>   :os:proc:/pid=7634/maps
>   :os:config:/max_processes
>   :ipc:sem:/uid=873/id=543
>   :fs:local:/blabla/ble/bli
>   :dev:snd:/card0

un peu deroutant au premier coup d'oeil, mais finalement pourquoi pas.
 
> C'est a dire :
>   - L'identifiant de la classe
>   - L'identifiant de l'instance de classe (le service)
>   - L'identifiant de l'objet manipule, en suivant la regle de nommage
>     du service (separation par des '/' ou par des virgules, ...)

pour toi les instances de classe ca serait proc, config, sem ou local.
Bin je crois que pour julien c'est pas tout a fait la meme chose. On
pourrait avoir une classe thread. Et puis ensuite une instance pour le
thread d'id 1, d'id 2, etc...
Mais bien sur ce que je dis ici ce n'est que ma propre opinion :)

> Pour l'instant, j'ose esperer que la VM peut se faire sans
> necessairement de Babel complet. par contre, il est vrai qu'on ne
> pourra faire du cpl3 serieusement qu'avec un Babel complet. Ceci dit,
> on peut quand meme commencer a faire du cpl3 de base, histoire de voir
> le mecanisme des call gates et des espaces d'adressage, sans Babel du
> tout. Le reste du boulot cpl3 sera presque exclusivement le
> developpement de Babel.

d'accord. par contre je galere toujours pour mes piles statiques. ca
fait depuis hier midi que je suis dessus, j'ai toujours rien trouve de
concret qui ferait avancer le pb.

thomas
-- 
PETAZZONI Thomas
thomas.petazzoni@meridon.com     UIN : 34937744
Projet KOS : http://kos.enix.org
Page Perso : http://www.enix.org/~thomas/