[Kos-dev] TODO : petits points necessitant explications

[Thomas Petazzoni]

salut,


j'ai vu que d2 avait rajouter deux petites choses dans le TODO, sur
lesquelles j'aimerais avoir de plus amples explications :

- le wrap around du jiffies

tout d'abord par defaut, on a pas 32bits de micro secondes max par
defaut, mais 2^32 de tick d'horloge, or si on est a 100Hz (comme sous
Linux), ca laisse pas loin de 42949672 secondes de delai (soit si je ne
me trompe 497 jours de delai). en effet, si le parametre de la fonction
usleep est passe en micro secondes, ce temps est converti en tick
d'horloges via la ligne :

new_sleeping_thread->expiration_time = jiffies + ((delay*HZ)/1000000);

(cf modules/scheduler/sleep.c)

==> conclusion : a mon avis pas la peine de s'embeter avec un wrap
around du jiffies, ca risque pas d'arriver de si tot.

- mapper le code kernel + rodata (a revoir dans loader) en read only en
partie virtuelle + Identity mapping

plusieurs remarques concernant ce probleme :
	1. le code, les donnees, et les rodata, ainsi que le bss du noyau (donc
des modules) sont melanges sur les memes pages physiques : chaque module
est sur des pages physiques differentes, mais les sections .text, .data
et .rodata peuvent etre reunis sur la meme page. d'ailleurs le loader
n'a meme pas connaissance de ces sections, car elles sont reunies au
sein d'une section .load ==> cf modules/module.lds. conclusion :
impossible que le code soit en R/O, et les donnees en R/W a moins de
modifier carrement le loader. de toute facon la remarque 2 detruira
cette possibilite
	2. si on se refere a la table 4.2 (page 4-31, chapitre 4,  volume 3 de
la doc intel), on peut voir qu'il n'est pas possible d'obtenir par
l'effet combine des droits d'acces des PTE et PDE une page virtuelle qui
soit en R/O lorsque l'on est en superviseur, ce qui est le cas pour les
pages de la partie noyau.

conclusion : mapper le code et le rodata du noyau en R/O est impossible.
de toute facon le noyau est cense etre bien code, et donc ne pas
s'autodetruire... enfin il est cense !

- macro EXPORT (vide) => dans macros.h

je precise pour ceux qui n'etaient pas la au moment ou nous avons cree
la macro : la macro EXPORT est une macro qui ne fait rien qui permet de
differencier au niveau d'un .h les fonctions qui sont reellement
exportees (appelees et appelables) de celles qui sont uniquement la pour
etre appelables depuis tous les .c du modules.

ex :

	EXPORT void cette_fonction_est_appelable_depuis_un_autre_module(void);
	void cette_fonction_n_est_pas_appelable_depuis_un_autre_module(void);

evidemment comme cette macro en fait rien, elle ne va pas empecher
l'appel d'une fonction depuis un autre module (c'est le role de la macro
EXPORT_SYMBOL dans le .c), mais elle est juste la pour se souvenir ce
qui est exporte et ce qui ne l'est pas.

- optimisation du flush_tlb a coup de invplg

invplg est-ce que c'est un truc qui marche sous bochs ? 
une fois que ceci sera verifie, l'implementation sera assez simple a mon
avis : il suffit de faire invplg et de lui passer en argument l'adresse
virtuelle qu'il faut flusher dans les TLB.

mais je crois que c'est dispo que sur les pentium (ou 486 ?). peut etre
on devrait mettre un place un truc au demarrage de KOS qui detecte les
capabilites du proc, pour pouvoir faire un test du genre

	if(cpu->invplg)
		invplg(address);
	else
		flush_tlb();

ca vous tente pas ?

voila pour les reflexions du jour,

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