Journal La gestion memoire sans MMU

Posté par  .
Étiquettes : aucune
0
20
avr.
2004
Le noyau 2.6 le Linux sait comment gérer la mémoire malgré l'absence de MMU donc l'absence de mémoire virtuelle et par conséquent cela rend impossible l'appel système fork() traditionnel tel que nous le connaissons (création d'un processus fils à partir d'un processus père en recopiant ses zones mémoires).
La gestion du multitâche grâce aux nouveaux mécanismes mis en œuvre est donc facilité par l’utilisation du noyau 2.6.2 comment ce dernier réalise donc se tour de passe-passe ( certainement grâce aux travaux sur uc-Linux) qui reste encor un mystère.

Idée de solution possible :

La MMU étant gère par notre Linux le mécanisme d'adressage pour ce dernier ne l'utilise pas (pour éviter la surcharge de travail pour des processus OS'ien)??

La chaîne pte_chain inclus dans la structure d'une page crée une simulation logiciel de la MMU et en plus favorise la libération de ces dernières??

Un petit troll de 3nm s’occupe de réaliser la traduction des adresses a la place de la MMU ??

Sinon je vois pas ...


Si quelqu'un sait comment est gère ce tour de force ??

  • # Re: La gestion memoire sans MMU

    Posté par  . Évalué à 1.

    Il me semble que le noyau linux tournait avant la version 2.6 sur des machines sans mmu. En fait les 386 ont introduit une gestion de mémoire paginée avec 4 niveaux de protection (je simplifie) et linux s'est appuyé dessus. Maintenant sur les processeurs risc (power pc, mips etc.) il n'y a pas les même choses.
    Donc à priori pas de soucis, le noyau linux sur Intel sait bien exploiter cette familles de processeurs !

  • # Re: La gestion memoire sans MMU

    Posté par  (site web personnel) . Évalué à 1.

    y'a simplement pas de translation d'adresses.

    Le process ne débute pas à zero mais à une adresse fixe donné par l'os. Il n'y a pas non plus de protection de lecture/écriture/execution (ou alors elle est sommaire)

    "La première sécurité est la liberté"

    • [^] # Re: La gestion memoire sans MMU

      Posté par  . Évalué à 1.

      Ce qui est peut être un des héritages de Minix (http://www.cs.vu.nl/~ast/minix.html(...)) dont Linus s'est inspiré pour créé Linux. Or Minix tournait sur 8086...

      • [^] # Re: La gestion memoire sans MMU

        Posté par  . Évalué à 1.

        Bein sur le 8086 la mémoire est segmenté -bein oui, technologie complétement dépassé par rapport au 68000 sorti en même temps.

        Donc il suffit d'avoir un segment Data et un autre EXE et ca fonctionne.
        Bien entendu, il n'y a absolument aucune protection, et n'importe quel programe peu changer l'offset du segment. En plus ca ne fait que 64 Ko donc il faut bidouiller..

    • [^] # Re: La gestion memoire sans MMU

      Posté par  . Évalué à 1.

      Ça veut dire, par exemple, que si je fais un malloc() puis un fork(), mon processus fils continuera à traiter avec la mémoire allouée pour mon processus père, jusqu"à ce que je lui réindique la bonne adresse ? (un exemple parmi tant d'autres...)

      Ça complique carrément la programmation, non ? M'enfin bon, je ne vois pas de solution miracle avec ou sans fork(), de toute façon -_-°.

      • [^] # Re: La gestion memoire sans MMU

        Posté par  . Évalué à 1.

        A mon avis sur ce type d'architecture il ne doit pas y avoir de fork... c'est vrai que c'est un peu plus compliqué, il faut compiler le code en "relocatable" ou recalculer toutes les adresses au chargement de l'executable, mais bon rien d'impossible, et pas grand chose de plus compliqué au niveau du programmeur...

        • [^] # Re: La gestion memoire sans MMU

          Posté par  . Évalué à 1.

          >A mon avis sur ce type d'architecture il ne doit pas y avoir de fork...
          'Faut bien créer de nouveaux processus quand même :-). M'enfin j'ai compris l'idée.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.