| Table des matières du Be Book | Index du kit du Noyau |
Une area est un gros morceau de mémoire virtuelle. En tant que telle, elle a toutes les propriétées attendues de la mémoire virtuelle : elle a une adresse de début, une taille, les adresses qu'elle contient sont contigues, et elle se projette (éventuellement de manière non-contigue) en mémoire physique (RAM). Les avantages qu'une area fournit que vous n'avez pas avec la mémoire "standarde" sont ceux-ci :
Parce que les areas sont grandes—une page, minimum—vous n'en créez pas arbitrairement. Les deux meilleures raisons de créer une area sont les deux premiers points de la liste ci-dessus : partager des données entre des applications différentes, et verrouiller la mémoire en RAM.
Y compris dans les détails (sauf un), vous traitez la mémoire qu'une area vous donne exactement comme vous traitez n'importe quelle mémoire allouée : vous pouvez la lire et y écrire par la manipulation de pointeur, ou par des fonctions standardes comme memcpy() et strcpy(). La seule différence entre la mémoire des areas et celle "mallocée" est...
Chaque area que vous créez est étiquettée par un area_id :
Les areas peuvent aussi être (vaguement) identifiées par un nom :
Pour que des multiples applications partagent une area commune, l'une d'entre elles doit créer l'area, et les autres cloner l'area. Vous clonez une area en appelant clone_area(). La fonction demande, comme premier argument, l'area_id de l'area source et retourne un nouveau (et unique) area_id. Toutes références ultérieures à l'area clonée (dans les applications clonant) doivent s'effectuer sur l'area_id que retourne clone_area().
Mais comment un cloneur trouve l'area_id de la source ?
Gardez à l'esprit que les noms d'area n'ont pas de contrainte d'unicité, donc la méthode find_area() a une part d'incertitude. Mais cela peut être réduit par la création ingénieuse du nom.
La mémoire physique sur laquelle repose une area n'est jamais implicitement copiée—par exemple, le mécanisme d'area n'accomplit pas une "duplication sur écriture". Si deux areas réfèrent la même mémoire suite à un clonage, une modification de données faite par le biais d'une area sera visible par l'autre area.
Lorsque vous travaillez avec une quantité modérée de donnés, vous souhaiterez souvent que les données reste en RAM, même si le reste de votre application a besoin d'être swappée. Un argument de create_area() vous permet d'indiquer, par l'usage de l'une des constantes suivantes, le schéma de verroullage que vous désirez appliquer à votre area :
| Constante | Signification |
|---|---|
| B_FULL_LOCK | La mémoire est verrouillée dans la RAM lors de la création de l'area, et ne sera jamais swappée. |
| B_CONTIGUOUS | Non seulement la mémoire de l'area est verrouillée en RAM, mais elle est aussi garantie d'être contigue. C'est particulièrement—et peut-être exclusivement—utile pour les concepteurs de certains types de pilotes de périphériques. |
| B_LAZY_LOCK | Des pages individuelles de mémoire sont amenées en RAM dans l'ordre naturel des choses et alors verrouillées. |
| B_NO_LOCK | Les pages ne sont jamais verrouillées, elles sont amenées en RAM ou descendues (swappées) sur disque selon le besoin. |
| B_LOMEM | C'est une constante spéciale, utilisée pour les areas qui doivent être verrouillées, contigues, et résider dans les premiers 16 Mo de mémoire physique. Les gens qui ont besoin de cette constante se reconnaitront. |
Gardez à l'esprit que verrouiller une area réduit essentiellement la quantité de RAM qui peut être utilisée par d'autres applications, et donc augmente la probabilité de swapping. Donc, ne verrouillez pas simplement parce que vous êtes gourmant. Mais si l'area que vous verrouillez est partagée entre plusieurs autres applications, ou si vous écrivez une application temps-réel manipulant de grosse quantité de données, alors le verrouillage peut être un abus justifiable.
Le shéma de verrouillage est positionné par la fonction create_area() et est immuable ensuite. Vous ne pouvez pas modifier le verrouillage lorsque vous clonez une area.
En fin de compte, vous utilisez une area pour la mémoire virtuelle qu'elle représente :vous créez une area parce que vous voulez de la mémoire dans laquelle vous pourrez écrire et y lire des données. Ces opérations s'effectuent de manière habituelle, par référence à des adresses spécifiques. Affecter un pointeur à une adresse à l'intérieur de l'area, et vérifier que vous n'avez pas dépassé les limites de la mémoire de l'area pendant que vous augmentez le pointeur (en lisant ou en écrivant) sont de votre propre responsabilité. Pour faire cela correctement, vous avez besoin de connaître l'adresse de début de l'area et sa dimension :
Un point important, en ce qui concerne area_info, est que le champ address est uniquement valide pour l'application qui a créé ou cloné l'area (autrement dit, l'application qui a créé l'area_id passé à get_area_info()). Bien que la mémoire sous-jacente à une area soit globale, l'adresse que vous retrouvez depuis une structure area_info réfère un espace d'adresse spécifique.
S'il y a le moindre doute si un area_id est "local" ou "étranger", vous pouvez comparer le champ area_info.team à la team de votre thread.
Lorsque votre application se termine, les areas (les area_id) qu'elle a créé par create_area() ou clone_area() sont automatiquement rendus invalides. La mémoire sous-jacente à ces areas, toutefois, n'est pas nécessairement libérée. La mémoire d'une area est libérée uniquement quand (et dès que) plus aucune area la réfère.
Vous pouvez forcer l'invalidation d'un area_id en le passant à la fonction delete_area(). A nouveau, la mémoire sous-jacente est seulement libéré si votre area est la dernière area réfèrant cette mémoire.
Détruire une area, explicitement par delete_area(), ou parce votre application se termine, n'affecte jamais le status des autres areas qui l'ont cloné.