[Kos-dev] VMM : zero, kmem, kstack, lien avec FS

[Thomas Petazzoni]

>>- zero
> 
> Pas très clair... pour résumer, tu définis ce "zéro" comme étant une façon
> analogue d'allouer de la "bss" sauf qu'il s'agit d'un "heap" pour le
> processus en cours ? on peut donc y lire et y écrire, sauf que si la page
> n'était pas présente lors d'un accès lecture/écriture, on alloue une page
> physique remplie de zéros (bref, comme pour le "bss" de linux). Je comprends
> moins l'intérêt de "raw_write" qui ne fait rien, en effet, comment
> comptes-tu gérer la mémoire virtuelle pour le tas, i.e, permettre au noyau
> de "swapper" les pages les moins utilisées si ce n'est pas "raw_write" qui
> en prend charge ? c'est là un détail que tu devrais m'éclairer.


raw_write et raw_read sont des methodes qui doivent etre obligatoirement 
proposées par tout driver de systeme de fichiers. raw_write sert 
simplement a prendre le contenu de la memoire pour le remettre dans le 
fichier qui a ete mappe sur le disque. par exemple si on mappe un 
fichier en lecture/ecriture, qu'on y fait des modifs, puis qu'on le 
demappe, il va bien falloir mettre ces modifs quelque part.... sur le 
disque grace a raw_write.

le mecanisme du swapping est completement decorele de tout cela, il se 
debrouille tout seul pour prendre des pages en memoire et les foutres 
sur le disque.


> Pour ma part, un "team" n'est pas une tâche mais une collection de tâches
> ("threads") ayant les mêmes ressources et le même espace virtuel. De fait,
> c'est bien le "thread" qui doit recevoir l'exception "user" indiquant un "
> BAD MEMORY ACCESS " (à savoir, ton SIGSEGV), car lui seul en est le vrai
> responsable du défaut de page qui n'a pu être résoulu. Les autres "threads"
> n'ont pas de raison d'être punis.


C'est effectivement la solution qui me paraissait la meilleure... Mais 
alors il faudrait prevoir quelque chose pour que si tous les threads 
d'une team ont ete killes, la team soit killee aussi.


> D'ailleurs, imaginez un jeu marant où "on" créé des "threads" génétiquement
> modifiables avec une sélection fondée sur l'élimination des "threads" de par
> des accès interdits en mémoire. Ce serait impossible de le réaliser si la
> punition s'appliquait à tous les "threads" du "team".


Le jeu de la vie en quelque sorte. Tu fais des erreurs, tu es blame par 
le systeme.

> Les deux sont possibles, simplement en rajoutant un paramètre d'allocation à
> la fonction kvalloc pour sélectionner le comportement à suivre :
> - la mémoire à allouer est petite et sûre d'être utilisée très rapidement :
> allocation immédiate.
> - la mémoire à allouer est très grande et seule une petite partie est
> finalement utilisée (choisie aléatoirement) : allocation "lazy" pour mieux
> coller à l'utilisation réelle.


J'aime pas trop rajouter des parametres optionels aux fonctions, apres 
c'est chiant a comprendre comment ca marche.
De toute facon, il est assez rare que le programmeur systeme ait a 
utiliser kvalloc, c'est plus directement kmalloc qu'il va utiliser (ou 
kslab_cache_alloc si il alloue plein de donnees de la meme taille). Et 
dans ce cas, si on rajoute un parametre a kvalloc, a partir de quelle 
taille de blocs on n'alloue plus automatiquement la page ?
Peut etre que si le bloc fait plus d'une page, ce n'est pas la peine de 
tout mapper effectivement. C'est une idee...


> Quelles expérimentations ? j'aimerais bien les connaître, les "preuves" qui
> infirment la possibilité d'agrandir dynamiquement la pile. J'ai autant de
> méfiance vis-à-vis de cette affirmation que j'en ai eu quand on me soutenait
> qu'il était impossible de faire du mode réel avec du code 32-bit par défaut.
> Cependant, je dois reconnaître que la gestion des piles dynamiques
> compliquent leurs manipulations à tous les niveaux et donc je comprendrais
> que l'on ne veuille pas s'hasarder dans cette aventure. Moi-même n'étant pas
> certain que cette gestion dynamique nous soit utile. En revanche, il nous
> faut en effet garder ce double fault pour nous prévenir d'un plantage
> général et pas seulement pour le déboguage.



David et moi avons travaille six mois sur le probleme du double fault et 
de l'agrandissement dynamique de pile au niveau noyau. Nous y etions 
presque, mais le materiel nous a battu. En effet, lorsque le double 
fault intervient pendant les pushs implicites du processeur pour entrer 
dans un handler d'irq, l'adresse ou a eu lieu le double fault n'est pas 
dans le handler d'irq, mais a l'endroit ou l'irq a eu lieu dans un 
certain thread. Ce n'est pas grave parce qu'on pouvait retrouver l'IRQ 
qui a eu lieu dans les registres du PIC, et la relancer manuellement. Or 
ceci fonctionnait bien tant que l'irq arrivait juste avant le dernier 
push implicite. Si l'irq arrive avant le deuxieme push implicite, et 
bien le registre du PIC n'est pas forcement a jour : parfois il l'est, 
parfois il ne l'est pas ? Commment savoir quelle est l'irq a relancer ? 
C'est impossible.



amicalement,

thomas
-- 
PETAZZONI Thomas
thomas.petazzoni@meridon.com
ICQ : 34937744
Projet KOS : http://kos.enix.org