[Kos-dev] Deux visions differentes de Babel

[Thomas Petazzoni]

d2 <David.Decotigny@irisa.fr> writes:

> Pour resumer, l'approche 2/ est moins "elegante", mais a l'avantage de
> maintenir ce qui doit etre intime au noyau, le plus proche possible du
> noyau, en evitant les pb de synchro, les lookup, ... le plus
> possible. Et peut-etre aussi un pb d'oeuf et de poule qd la memoire
> est limite (pas sur). Evidemment, il faut creer un babel pour
> disk_service pour que l'utilisateur cpl3 puisse jouer avec des
> partitions. Mais c'est pas vraiment une dupplication de code (vu qu'on
> ne reecrit pas les drivers disque). Et puis d'autre part, ca n'empeche
> pas que le noyau peut quand meme utiliser des trucs exotiques babel
> (carte tuner TV par exemple) pour swapper des trucs dessus ou faire du
> reseau (moyennant le codage d'un wrapper noyau -> l'objet babel).

Donc Babel fait des wrapper dans le sens user->kernel, et il aura
aussi besoin de wrapper dans l'autre sens !

De plus, le noyau a besoin des systemes de fichiers, pas seulement des
partitions, en effet, pense au file mapping ! La VMM doit pouvoir
acceder au contenu d'un fichier, via un systeme de fichiers, donc
acces a la table de montage, etc... !

> Revoir quand meme la liste des trucs qui sont "intimes" au noyau. Je
> pense a partition (ou disques, je sais pas[1]) et a net, mais je pense
> qu'il y a aussi console. Le reste (son, video, serial, ...), je pense
> pas que ce soit critique si le noyau est oblige de passer par Babel
> pour que le noyau puisse swapper/faire du reseau dessus.

Moi ce qui m'ennuie dans cette approche, c'est ce cote a part que tu
donnes arbitrairement a certains peripheriques.

Concernant les problemes de synchro, de lookup... Je sais pas si c'est
franchement pire que d'avoir des interfaces au niveau du noyau plus
des interfaces au niveau Babel...

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni@enix.org - UIN : 34937744
(Perso)      http://www.enix.org/~thomas/
(KOS)        http://kos.enix.org/ 
(Club LinUT) http://club-linut.enix.org