protection mémoire
-
J’espère un jour justement voir autre chose que Unix…
Et, pourquoi pas, des nouveautés que l’on ne retrouve dans aucun système « moderne » actuel
Dans ce cas pourquoi tant décrier les tentatives de nos OS NG actuels pour essayer de faire de la protection mémoire autrement ?
Un système moderne, qui n’a pas pour théorie « tout est un fichier » (oui, Unix c’est ça).
Oui et c’est peut-être l’un de ses gros point fort je trouve… D’ailleurs tu as un peu la même chose sous AOS avec les devices RAM: PIPE: SPEAK: RANDOM: etc.
on évite les commandes de 3 caractères
Mince on pourra plus faire DIR ou CD alors
Qui, conserve quelques points de l’Amiga que l’on apprécie (les assign, la ram-disk, …).
Le ramdisk existe sous Linux depuis longtemps, d’ailleurs c’est comme ça que tu lances l’installation de Linux : tu boutes sur un ramdisk dont le contenu est chargé depuis une image sur disque… (et je ne te parle pas non plus des outils -dont j’ai oublié le nom – qui permettent de faire ça sous [d]xxxxxxxxx[/d] l’os interdit
)Passer ma vie sur un Unix, ou passer mon temps à développer sur un système qui a 10 de retard sur tout ne m’intéresse pas.
Dans ce cas désolé pour toi mais il ne te reste plus qu’une seule solution –> elle est là
/ 
perso je ne suis pas DEV, sinon ça se saurai, mais quel est l’intérêt d’un protection mémoire sur amiga, vu la légéreté des softs, peut être avec les sdl, et encore peut-être que je confond accés proc. et accés mem.
1 A500 2mo, 1 A500 512ko +ACA500+, 1 A 1200 quasi neuf, 1 Atari 520Ste 4mo + UltraSatan dual, 1 Falcon030 avec DFB1X , 1 MSX2 8235 avec Carnivore2, 1 MSX28250 (fmstéréopack, music mode, MegaFlashRom et quelques D7 et KTouche ).
maxime perpétuelle : si je cours en zigzag ce n'est pas pour éviter le balles, mais les c..s, et si un cachalot vient sur ton babord, il est prioritaire, sur tribord aussi... (B.M.)@JiDeWe: ne pas avoir d’adressage memoire protégé discredite notre OS preferre et contribu à faire en sorte que personne ne s’y interesse.
Personnellement je vois ça comme ça, même si, comme je l’ai dit, pour mon usage à moi je m’enfout un peu.
C’est un minimum si on se veut être un OS moderne, maintenant on peut se moquer d’être considéré comme archaique et ridicule mais sur le (tres) long terme il serait bien que du « sang frais » s’interesse à notre machine.
sas perso je pense que ca n’a rien à voir, un os est interessant si il a des applications interessante, exemple beos sur X86 : simple rapide efficace protection memoire stabilite de la mort qui tue est …. moins d’utilisateur que l’amigaos4…. apres il est clair que pour la robustesse de ‘los ce serait un plus quitte a y perdre un poil de legerete au niveau temps de reponse, helas samantha et surtout efika n’apprecieraient pas le changement vu leur petit proc.
Un peg2 ne souffrierais pas trop reste à voir à qui et pourquoi se destine nos os.
Le PSG qui gagne la ligue des champions c'est possible ... Que dans Swos.
Amiga Morphos Rules.@Alex: t’as mal lu… C’est tout simple pas possible d’avoir quelque chose d’efficace avec l’architecture actuelle. Point.
Pour la RAM-Disk, elle fait partie intégrante du système sur amiga. A tel point que les réglages (ENV:) sont par défaut sauvegardés là. Je ne dis pas que sur Linux c’est un hack,… seulement que 100% des AOS ont la RAM-Disk, et qu’elle est utilisée dès le boot. Ca fait partie du système… La RAM-Disk on la retrouve évidemment partout ailleurs. Mais c’est pas la question.
@+,
Léo.
Quel thread !
En fait, tout le truc, c’est : que va t’il se passer quand le sprite (ou bob) sort de l’écran ?
Faut – il crasher tout le système ?
De toute facon, le développeur, va corriger son programme pour que le bob reste TOUJOURS dans l’écran.
Faut – il choisir un environnement plus adapté qui gère dés la compilation du programme, ce genre de test ?
Faut – il un systeme d’exploitation miracle qui, quelque soit le compillateur, ou bug de développeur, peut empêcher un crash ?
Pour le développeur, quand ca crash, il y a un bug et il faut le corriger jusqu’a obtenir un code correct.
Tout le truc, c’est quand le fait de faire sortir le bob de l’écran va avoir un effet de bord passable ou pas.
En fait quand le bob sort de l’écran, il écrit en mémoire des données qui ne lui sont pas réservées, et elles peuvent être soit vide, soit déjà utilisées pour stocker des autres données ou programme et donc faire crasher le système.
Le plus dangereux, c’est quand mon propre programme tappe dans la mémoire alouées par cygnusEd, et que ca détruit mon code source. La j’enregistre un source corrompu et je perds tout et je ne peux plus corriger le bug.
C’est peu être aussi de la faute du joueur qui à emmené son personnage à un endroit non prévu par le développeur.
Finallement, c’est un peu comme pour les virus : il faut faire des sauvegardes !
JiDeWe a écrit :
perso je ne suis pas DEV, sinon ça se saurai, mais quel est l’intérêt d’un protection mémoire sur amiga, vu la légéreté des softs, peut être avec les sdl, et encore peut-être que je confond accés proc. et accés mem.
Bonjour,
Comme on dit que « l’erreur est humaine », il est préférable de disposer de la protection mémoire pour éviter un plantage système si l’application executée est mal conçue. Si tout le monde programmait bien elle n’aurait plus aucun interet dans ce sens.
En revanche, elle est surtout utile dans un système multi-utilisateurs telle qu’elle est présentée dans les systèmes UNIX. Chaque programme (Je ne parle pas en mode noyau) croit voir la mémoire en linaire, même si physiquement elle est fragmentée. Impossible pour un programme de scruter la mémoire d’un autre programme. Cela permet la protection des données confidentielles.
Dans le cadre des drivers par contre, c’est le mode noyau, on est confronté aux mêmes problèmes que l’AmigaOS. La mémoire est fragmentée et partagée. Si tu avais l’habitude de profiter du ressource tracking et compagnie, tu risques de te heurter aux mêmes problèmes et tu auras interet à augmenter ta rigueur.
On pourrait réaliser un micro-noyau à la QNX aussi, où il existe plusieurs niveaux de protection. Un driver fonctionne en niveau protégé. Mais faut le réflechir…
Rien est impossible pour implémenter de la mémoire protégée sur Amiga, mais cela se fera difficilement dans le sens d’UNIX. Le concept des messages port à mémoire partagée est excellent et simple à comprendre. Mais cela devient un casse tête pour l’implémenter en notion de mémoire protégée linéaire, bien qu’un pointeur, en tant que nombre, peut-être considéré comme une référence, mais le message contient souvent d’autres pointeurs (le programmeur doit penser autrement). A méditer…
D’autres parlent de repartir de zéro, mais on est plus dans la philosophie AmigaOS. Si tu es utilisateur, tu n’y vois que tu feu. Seul (presque) le visuel compte (on voit cela avec l’OS Mac), mais la tu as affaire à des programmeurs qui aiment le concept de messages port etc etc… T’auras du mal à nous convaincre de supprimer ces concepts pour au final adopter un concept UNIX like. Autant passer sous Unix dans ce cas, je crois d’ailleurs qu’il existe des Skins pour les puristes…
a+
Sreg
A ce sujet, WhdLoad semble faire de la protection mémoire, puisque tous les softs exécutés par ce moyen permettent un retour au WB même si le jeu est bloqué. Toutes les ressources mémoires sont libérées.
Car bien sur la mémoire n’est ni protégée, ni alouée en fonction d’un processus et automatiquement libérée quand le processus qui l’utilise se termine.
En ce qui me concerne, je pense à partir du moment où l’on veut de la protection de mémoire logicielle (autre que le mmu), il vaut mieux le gérer dans le compilateur que dans le système d’exploitation.
Le compilateur E par exemple, à défaut de protéger la mémoire, libere au moins tout ce qui a été aloué.
L’amigaOs est lui même protégé, puisqu’il est situé en ROM.
D’autres parlent de repartir de zéro, mais on est plus dans la philosophie AmigaOS. Si tu es utilisateur, tu n’y vois que tu feu. Seul (presque) le visuel compte (on voit cela avec l’OS Mac), mais la tu as affaire à des programmeurs qui aiment le concept de messages port etc etc… T’auras du mal à nous convaincre de supprimer ces concepts pour au final adopter un concept UNIX like. Autant passer sous Unix dans ce cas, je crois d’ailleurs qu’il existe des Skins pour les puristes…
Hum… Et c’est quoi la « philosophie » AmigaOS ? J’ai bien peur de ne pas adhérer… Et pourtant d’apprécier certains concepts de ce système. Qu’on ne retrouve nulle part ailleurs (et surement pas dans un Unix avec un Skin… D’ailleurs, l’interface est un des trucs que je changerai, puisqu’elle est moche, et relativement peu intuitive…)
Qui parle d’enlevever les messages port ? Pourquoi ne pas les conserver, mais utiliser la copie ?
@+,
Léo.
leo a écrit :
Hum… Et c’est quoi la « philosophie » AmigaOS ? J’ai bien peur de ne pas adhérer… Et pourtant d’apprécier certains concepts de ce système. Qu’on ne retrouve nulle part ailleurs (et surement pas dans un Unix avec un Skin… D’ailleurs, l’interface est un des trucs que je changerai, puisqu’elle est moche, et relativement peu intuitive…)
Qui parle d’enlevever les messages port ? Pourquoi ne pas les conserver, mais utiliser la copie ?
@+,
Léo.
La philosophie c’est le système de message par exemple, de library, de device, tels qu’ils sont présentés dans l’AmigaOS.
N’oublie pas que l’on cherche aussi à rester compatible. Sur Amiga un transfert de message doit être 100% fiable. Aucune erreur possible. Dans un concept de copie, il faudrait une allocation qui risquerait d’échouer. On peut aussi imaginer que la tâche qui recoit le message ait réservé à l’avance (par logique de code du programmeur) un espace mémoire mais on s’éloigne du concept initial.
Le mieux, comme je le laissais penser, est de considérer le pointeur message comme une référence. Le temps du transfert de message celui-ci se trouverait en mémoire partagée. On trouve aussi cela sous Unix pour partager la mémoire entre deux process (shmat() et cie). Rien empeche la mmu de considérer une même zone mémoire physique sur 2 adresses différentes pour chaque process. Par contre il faudra faire attention à ne plus transferer de pointeurs dans le message (lui même limité à 65ko). On perd forcémement la compatibilité source.
Ok sur AmigaOS4 on a pas la mémoire linéaire et les developpeurs ont quand même imaginé des principes d’allocation limitant fortement la fragmentation mémoire, mais sans cette mémoire linéaire, on peut implementer une autre forme de protection mémoire qui permet une bonne compatibilité avec l’existant, sans pour autant changer fondamentalement le système.
Un exemple inventé de ma part est de protéger une allocation en l’allouant de la sorte:
AllocVec(10000,MEMF_ANY|MEMF_CLEAR|MEMF_READONLY)
ou encore:
AllocVec(10000,MEMF_ANY|MEMF_CLEAR|MEMF_PROTECT)
C’est bien sûr des exemples. Je ne sais pas comment c’est implémenté dans OS4.
a+
Sreg
Ca n’empèche pas les buffers overflow et d’aller écraser d’autres bouts de mémoire alloués sans ces flags. Cela n’empèche pas non plus d’aller lire les données des autres programmes en mémoire.
Warpup proposait déjà inutilement ce genre de fonctionnalité ridicule comparée aux autres OSes.
Et dire que certains ventent les mérites d’une telle merde en clamant que c’est une manière différente (et plus « amiga » ?) d’implémenter la protection mémoire… tsss…
Moi je m’en fou de rester compatible…
S’il faut la zapper pour avancer (et apparement c’est le cas), alors faisons-le… Pourquoi garder la compatibilité avec des applications vieilles et si limitées (et pour la plupart desquelles les sources ne sont pas dispo., donc ne pourront plus être mises à jour) ?
Moi je vois pas… L’ABox est là, et fournit un niveau de compatibilité plus que suffisant… Certains disent que c’est leur machine principale: donc c’est largement suffisant pour démarrer, non ? Alors hop: on freeze ici le développement de l’ABox, et on attaque autre chose, en s’affranchissant de toutes ces limites… Les messages c’est bien ? et bien on les utilise. Les devices c’est bien ? Alors on fait de même. Les datatypes c’est bien mais trop limité ? Alors on développe quelque chose de mieux… Ce qui serait génial, c’est qu’on aurait *aucune* limite dans le développement du système… Puisqu’aucune compatiblité à conserver, l’ABox étant là pour ca. Je comprends pas pourquoi on s’impose toutes ces contraintes…
@+,
Léo.
leo a écrit :
Moi je m’en fou de rester compatible…
S’il faut la zapper pour avancer (et apparement c’est le cas), alors faisons-le… Pourquoi garder la compatibilité avec des applications vieilles et si limitées (et pour la plupart desquelles les sources ne sont pas dispo., donc ne pourront plus être mises à jour) ?
Oui mais à ce niveau il s’agit même de la compatibilité au sein du sytème. Intuition ne pourrait même plus marcher dans un fonctionnement à la Unix par exemple. Cela vient du fait que nous echangeons des zones mémoires entre process.
Changer tout cela, c’est presque changer de système. Rappelons que le système n’est pas l’aspect visuel. (Ca c’est l’environnement)
On peut toutefois garder ce principe dans une gestion de threads où la mémoire reste partagée. Mais en inter-process avec la mémoire protégée et linéaire, ce n’est pas possible dans l’état actuel des choses.
Hors un device, par exemple, fonctionne en inter-process par échange de pointeurs.
Je pense quand même que par l’ajout de couches on peut garder le concept qui nous plait tant.
Pour le reste, le principe de protéger certaines zones mémoire reste interessant si l’on souhaite garder le concept tel quel. Dans mon exemple où j’utilisais le flag MEMF_PROTECT, cela voudrait dire que la mémoire est propre au process et illisible en lecture/écriture pour un autre process. Hélas, cela n’empêche pas la fragmentation mémoire du point de vue du process.
Mais tout n’est que question de point de vue. Sous Unix, la mémoire est bel et bien fragmentée mais la MMU s’éfforce d’en donner une autre allure au process. C’est au détriment de la vitesse mais avec les processeurs actuels, même sur Amiga, on ne verrait pas cette perte avec une vitesse déjà multipliée par x.
a+
Sreg
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Général › protection mémoire
