Des nouvelles de l’AmiGBG en Suède

Ok, c’est corrigé.
Merci, Julien, pour ton expertise.

a+
Seg.

Auteur: Fab1 Posté le: 29/7/2005 14:18:35

Protéger le code, pourquoi pas, mais statistiquement, tu exploses surtout les données (dépassements, écriture dans des zones qui ne sont plus valides) ou la page 0 (pointeurs nuls). Bien sûr, les pointeurs fous eux peuvent affecter aléatoirement données ou code

En pratique, je dirais quand même que cette protection du code ne couvre qu’une infime partie des plantages potentiels.

Bien sur. D’ailleurs, je n’ai pas dit que c’etait LA protection memoire, mais c’est une partie de son implementation. En tout cas, c’est ce qu’on peut deja faire sans adopter une architecture memoire a la Unix qui remettrait en cause tout le reste. D’ou ma petite anotation disant que cela reduisait « statistiquement » les cas de plantages.

Par contre, je ne suis pas tellement d’accord avec toi concernant les risques statistiques. Bien sur, tout est affaire d’experience sur ce sujet. On peut etablir des theories mais on arrivera jamais vraiment a prouver que toi ou moi avons raison la dessus. Ca ne pourra se demontrer qu’a l’usage, statistiquement.

Mais bon, puisqu’on est la pour partager nos idees… moi je pense que blinder le code est plus primordial que le reste si l’on doit considerer des ordres de priorite independamment du fait que l’ensemble du mecanisme est important.
Donc, de mon point de vue, je pense qu’un code detruisant un autre code entraine encore plus de risques de pointeurs fous, ce qui peut entrainer des reactions en chaine plus ou moins graves.
Mais un pointeur fou, ca peut s’arreter. Un code qui s’execute au pif, ca peut s’arreter aussi. Et si on a la chance que ca s’arrete ou que ca tourne en rond quelque part sans dommage, alors tout ce bordel aura fait le moins de casse possible.
Maintenant, mettons qu’un pointeur fou est passe par les donnees d’un programme:
Si c’est la cache d’un filesystem, ca peut etre desagreable, je sais bien.
Si c’est les ressources d’une application, genre le gui, ca peut se remarquer a l’usage et on peut quitter l’application sans trop de risques.

Difficile d’avoir un avis tranché. Notre tache est donc de faire travailler notre imagination pour savoir s’il y a plus d’autres cas ou les donnees sont critiques pour le bon deroulement d’une tache par rapport au systeme. Par exemple, il y a beaucoup de structures contenant des pointeurs sur d’autres structures etc. Peut-on trouver plus de structures contenant des pointeurs sur des fonctions? etc etc…

Je ne pense pas que mes exemples soient tres convaincant pour toi mais voila un chouilla comment je vois les choses 🙂

En tout cas, je pense que le blindage du code a un interet utile. Pourquoi s’en passer s’il est possible de le faire?

—

Maintenant, pour donner mon avis par rapport a ce qu’ecrit Henes au sujet de l’occupation memoire, je reprends un extrait:

Auteur: Henes Posté le: 29/7/2005 15:07

Et réduit drastiquement l’espace d’adressage utilisable donc la mémoire disponible pour les données des programmes. Ou inversement, réduit le nombre et l’importance des programmes que l’OS peut faire fonctionner.
Et entraine des exceptions donc des dégradations des performances pures sans parler du multitâche amoindrit.

Bon, je ne suis pas developpeur OS4, mais j’imagine qu’ils n’ont pas divisise l’espace en 3 zones distinctes. Je pense que l’ensemble fonctionne avec le fameux manager dont je parlais, qui se charge d’allouer des pages memoire d’une taille definie par eux (les developpeurs), des que le systeme en a besoin.
Ca fonctionne comme ca sous Unix ou sous Windows et ca marche plutot bien.
Unix possede aussi (peut-etre pas tous les Unix) un systeme de defragmentation de ces pages pour reduire la taille des tables MMU et ameliorer les performances.
Ce mecanisme ne peut etre efficacement implementé dans OS4 vu que l’espace memoire est partagé.

Mais ATTENTION!!! Tout ce que j’ecris la ne sont que des suppositions qui n’engagent que moi.

a+
Seg.