De nombreux OEM Android modifient le pilote du noyau ION pour diverses raisons, par exemple : l'ajout des segments de mémoire des fournisseurs et la personnalisation de la gestion du cache (pour en savoir plus consultez la page Intégrer la mémoire ION outil d'attribution). Pour permettre aux OEM de conserver ces modifications lors de l'utilisation de l'attribut Generic Kernel Image (Image du noyau générique) (GKI), Android Common Kernel v5.4 introduit un framework permettant de modulariser une instance ION spécifique au fournisseur des segments de mémoire tout en laissant le pilote ION principal intégré. La figure suivante illustre le la mise en page des images du noyau.
Figure 1 : Pilote de noyau ION modulaire
Les tas de mémoire ION modulaires présentent les avantages suivants.
- Le pilote ION Core peut faire partie de l'image GKI, des optimisations de performances indépendantes de l'appareil et des corrections de bugs pour atteindre tous appareils.
- Le pilote principal ION dans le noyau commun peut gérer l'enregistrement de segments de mémoire et gérer l’interface avec l’espace utilisateur et les clients du noyau. Les modules de segment de mémoire du fournisseur ne sont nécessaires que pour implémenter les opérations personnalisées sur les segments de mémoire.
- Le pilote principal ION (dans le cadre de GKI) peut inclure des hooks pour faciliter la mémoire. ce qui n'était pas possible lorsque chaque OEM disposait de sa propre version le pilote ION.
- Les tas de mémoire ION du fournisseur modulaires doivent effectuer toute transition vers les tas de mémoire
dmabuf
à l'avenir plus facile.
Implémentation
Les modules de segment de mémoire ION peuvent enregistrer leurs propres opérations dmabuf
pour remplacer celles
enregistré par le pilote ION principal. Une opération dmabuf
(telle que get_flags()
)
qui n'est pas compatible avec le pilote ION principal renvoie -EOPNOTSUPP
si le segment de mémoire
ne dispose pas des forçages nécessaires.
Pour améliorer les performances, le pilote dmabuf
peut effectuer un cache partiel.
la maintenance (voir
changelist, par exemple).
Les clients du noyau peuvent utiliser dma_buf_begin_cpu_access_partial
et
dma_buf_end_cpu_access_partial
pour effectuer une maintenance partielle du cache.
Le noyau commun Android contient des implémentations modulaires du système et Des tas de mémoire d'allocation de mémoire contiguë (CMA) à utiliser comme référence pour les segments de mémoire et la modularisation.
Modifications apportées à l'en-tête ION UAPI
L'en-tête de l'API User Space (UAPI) ION contient une énumération ion_heap_id
à utiliser dans
définir une plage d'ID de tas de mémoire à utiliser par les tas de mémoire des fournisseurs.
/**
* ion_heap_id - list of heap IDs that Android can use
*
* @ION_HEAP_SYSTEM ID for the ION_HEAP_TYPE_SYSTEM
* @ION_HEAP_DMA_START Start of reserved ID range for heaps of type ION_HEAP_TYPE_DMA
* @ION_HEAP_DMA_END End of reserved ID range for heaps of type ION_HEAP_TYPE_DMA
* @ION_HEAP_CUSTOM_START Start of reserved ID range for heaps of custom type
* @ION_HEAP_CUSTOM_END End of reserved ID range for heaps of custom type
*/
enum ion_heap_id {
ION_HEAP_SYSTEM = (1 << ION_HEAP_TYPE_SYSTEM),
ION_HEAP_DMA_START = (ION_HEAP_SYSTEM << 1),
ION_HEAP_DMA_END = (ION_HEAP_DMA_START << 7),
ION_HEAP_CUSTOM_START = (ION_HEAP_DMA_END << 1),
ION_HEAP_CUSTOM_END = (ION_HEAP_CUSTOM_START << 22),
};
De plus, un nouveau IOCTL
(ION_IOC_ABI_VERSION
) peut aider les clients de l'espace utilisateur
déterminer si des tas de mémoire modulaires sont utilisés.
Remplacer le tas de mémoire générique du système
Le tas de mémoire du système ION est intégré et fait partie de l'image GKI pour garantir
qui a besoin d'accéder à un tas de mémoire générique/indépendant de l'appareil peut dépendre
leur existence. Par conséquent, vous ne pouvez pas remplacer l'ID du tas de mémoire de ION_HEAP_SYSTEM
. À
créer un tas de mémoire système personnalisé, utiliser un ID de tas de mémoire compris dans la plage personnalisée
(ION_HEAP_CUSTOM_START
à ION_HEAP_CUSTOM_END
) pour effectuer des allocations.