De nombreux OEM Android modifient le pilote du noyau ION pour diverses raisons, telles que l'ajout de tas de fournisseurs et la personnalisation de la gestion du cache (pour en savoir plus sur ces modifications, consultez la section Intégrer l'outil d'allocation de mémoire ION). Pour permettre aux OEM de conserver ces modifications lors de l'utilisation de l'image de kernel générique (GKI), Android Kernel commun v5.4 introduit un framework permettant de modulariser les tas ION spécifiques au fournisseur tout en conservant le pilote ION principal intégré. La figure suivante présente la mise en page de l'image du noyau.
Figure 1 : Pilote de kernel ION modulaire
Les tas de mémoire ION modulaires présentent les avantages suivants.
- Le pilote de noyau ION peut faire partie de l'image GKI, ce qui permet à toutes les optimisations de performances et corrections de bugs indépendantes de l'appareil d'atteindre tous les appareils.
- Le pilote de noyau ION du noyau commun peut gérer l'enregistrement de tas et gérer l'interface vers l'espace utilisateur et les clients du noyau. Les modules de tas du fournisseur ne sont nécessaires que pour implémenter les opérations de tas personnalisées.
- Le pilote principal ION (dans le cadre du GKI) peut inclure des crochets pour faciliter le suivi de l'utilisation de la mémoire, ce qui n'était pas possible lorsque chaque OEM disposait de sa propre version du pilote ION.
- Les tas de mémoire ION du fournisseur modulaires devraient faciliter toute transition ultérieure vers des tas de mémoire
dmabuf.
Implémentation
Les modules de tas ION peuvent enregistrer leurs propres opérations dmabuf pour remplacer celles enregistrées 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 l'implémentation du tas de mémoire ne dispose pas des remplacements nécessaires.
Pour améliorer les performances, le pilote dmabuf peut effectuer une maintenance partielle du cache (voir la liste de modifications).
Les clients du noyau peuvent utiliser les fonctions 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 des tas de mémoire du système et de l'allocateur de mémoire contigu (CMA) à utiliser comme référence pour la modularisation des tas.
Modifications apportées à l'en-tête de l'UAPI ION
L'en-tête de l'API (UAPI) de l'espace utilisateur ION contient une énumération ion_heap_id à utiliser pour définir une plage d'ID de tas à utiliser par les tas du fournisseur.
/**
* 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 modulaires sont utilisés.
Ignorer la mémoire tampon système générique
Le tas de mémoire du système ION est intégré et fait partie de l'image GKI pour garantir que toute fonctionnalité nécessitant un accès à un tas de mémoire générique/indépendant de l'appareil peut dépendre de son existence. Par conséquent, vous ne pouvez pas remplacer l'ID de tas de ION_HEAP_SYSTEM. Pour créer un tas système personnalisé, utilisez un ID de tas dans la plage personnalisée (ION_HEAP_CUSTOM_START à ION_HEAP_CUSTOM_END) pour effectuer des allocations.