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

[d2]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@ifrance.com> writes:
    Thomas> la classe mere ca pourrait etre rien.

"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...

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

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.

    Thomas> en fait je pense que mon probleme etait mal pose : une
    Thomas> fois qu'on a notre abstraction en objet (qui me semble
    Thomas> etre la meilleure) comment va-t-on representer ca
    Thomas> physiquement ?

Ce n'est pas un probleme de representation physique, mais un probleme
d'"espace de nommage". Sous Unix, c'est vrai que c'est tres clair :
(presque) tous les objets manipules sont accessible a partir d'une
racine. Puisque tout est objet-fichier, cette racine est un
repertoire, et a partir de la, l'espace de nommage colle avec une
representation """physique""". 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.

Moi, je verrais bien un fonctionnement a la "URL" :

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

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, ...)
Avec pour chaque service, la possibilite d'avoir des objets "lien"
vers d'autres objet.

Par exemple :
  :fs:local:/dev/audio -> :dev:snd:/card0/char_interface

C'est une proposition. L'espace de nommage est toujours un peu
complexe.

    Thomas> un autre probleme, plus urgent : si on considere que les
    Thomas> teams et threads doivent etre des objets enregistres dans
    Thomas> Babel, faudrait peut etre s'en preoccuper maintenant, et
    Thomas> donc avoir un Babel final. je sais qu'on a deja quelque
    Thomas> chose de fonctionnel, mais je sais aussi que Julien veut
    Thomas> encore changer des choses. je sais qu'on a pas
    Thomas> d'IDL. bref, est-ce viable de continuer a coder alors
    Thomas> qu'il faudra *surement* refaire des choses pour que ca
    Thomas> colle avec les interfaces generees par notre IDL ?

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.

Bonne journee,

-- 
d2