Les appareils livrés avec le noyau 4.14 et supérieur sont affectés par une refactorisation majeure du module du noyau Ion , que de nombreuses implémentations de couche d'abstraction matérielle (HAL) d'allocateur de mémoire graphique (gralloc) de fournisseurs appellent pour allouer des tampons de mémoire partagée. Cet article fournit des conseils sur la migration du code du fournisseur existant vers la nouvelle version d'Ion et discute des futures ruptures possibles de l'interface binaire d'application (ABI).
À propos de Ion
Ion fait partie de l' arborescence intermédiaire des travaux en cours du noyau en amont. Pendant la phase de préparation, l'ABI espace utilisateur-noyau d'Ion peut être interrompu entre les principales versions du noyau. Bien que les ruptures d'Ion ABI n'affectent pas directement les applications ordinaires ou les appareils déjà lancés , les fournisseurs migrant vers de nouvelles versions majeures du noyau peuvent rencontrer des changements qui affectent le code du fournisseur appelant dans Ion. De plus, de futures ruptures d'ABI pourraient survenir lorsque l'équipe des systèmes Android travaillera en amont pour déplacer Ion hors de l'arborescence intermédiaire.
Changements dans Android-4.14
Le noyau 4.12 a fortement refactorisé le code du noyau Ion, nettoyant et supprimant les parties d'Ion qui chevauchaient avec d'autres frameworks du noyau. En conséquence, de nombreux ioctls Ion existants ne sont plus pertinents et ont été supprimés.
Suppression des clients et des poignées Ion
Avant le noyau 4.12, l'ouverture /dev/ion allouait un client Ion . L'ioctl ION_IOC_ALLOC a alloué un nouveau tampon et l'a renvoyé à l'espace utilisateur en tant que handle Ion (un entier opaque significatif uniquement pour le client Ion qui l'a alloué). Pour mapper les tampons dans l'espace utilisateur ou les partager avec d'autres processus, les descripteurs Ion ont été réexportés en tant que fds dma-buf à l'aide de l'ioctl ION_IOC_SHARE .
Dans le noyau 4.12, l'ioctl ION_IOC_ALLOC génère directement les fds dma-buf. L’état intermédiaire du handle Ion a été supprimé, ainsi que tous les ioctls qui consomment ou produisent des handles Ion. Étant donné que les fds dma-buf ne sont pas liés à des clients Ion spécifiques, l'ioctl ION_IOC_SHARE n'est plus nécessaire et toute l'infrastructure client Ion a été supprimée.
Ajout d'ioctls de cohérence de cache
Avant le noyau 4.12, Ion fournissait un ioctl ION_IOC_SYNC pour synchroniser le descripteur de fichier avec la mémoire. Cet ioctl était mal documenté et peu flexible. En conséquence, de nombreux fournisseurs ont implémenté des ioctls personnalisés pour effectuer la maintenance du cache.
Le noyau 4.12 a remplacé ION_IOC_SYNC par l' DMA_BUF_IOCTL_SYNC ioctl défini dans linux/dma-buf.h . Appelez DMA_BUF_IOCTL_SYNC au début et à la fin de chaque accès CPU, avec des indicateurs spécifiant si ces accès sont des lectures et/ou des écritures. Bien que DMA_BUF_IOCTL_SYNC soit plus détaillé que ION_IOC_SYNC , il donne à l'espace utilisateur plus de contrôle sur les opérations de maintenance du cache sous-jacentes.
DMA_BUF_IOCTL_SYNC fait partie de l'ABI stable du noyau et est utilisable avec tous les fds dma-buf, qu'ils aient été alloués ou non par Ion.
Migration du code du fournisseur vers Android-4.12+
Pour les clients de l'espace utilisateur , l'équipe des systèmes Android encourage fortement l'utilisation de libion plutôt que les appels ioctl() à codage ouvert. Depuis Android 9, Libion détecte automatiquement l'Ion ABI au moment de l'exécution et tente de masquer toute différence entre les noyaux. Cependant, toutes les fonctions Libion qui ont produit ou consommé des handles ion_user_handle_t ne fonctionnent plus après le noyau 4.12. Vous pouvez remplacer ces fonctions par les opérations équivalentes suivantes sur dma-buf fds, qui fonctionnent sur toutes les versions du noyau à ce jour.
| Appel ion_user_handle_t hérité | Appel dma-buf fd équivalent |
|---|---|
ion_alloc(ion_fd, …, &buf_handle) | ion_alloc_fd(ion_fd, ..., &buf_fd) |
ion_share(ion_fd, buf_handle, &buf_fd) | N/A (cet appel n'est pas nécessaire avec dma-buf fds) |
ion_map(ion_fd, buf_handle, ...) | mmap(buf_fd, ...) |
ion_free(ion_fd, buf_handle) | close(buf_fd) |
ion_import(ion_fd, buf_fd, &buf_handle) | N/A (cet appel n'est pas nécessaire avec dma-buf fds) |
ion_sync_fd(ion_fd, buf_fd) | If (ion_is_legacy(ion_fd)) |
Pour les clients intégrés au noyau , étant donné qu'Ion n'exporte plus d'API orientées noyau, les pilotes qui utilisaient auparavant l'API du noyau Ion intégrée au noyau avec ion_import_dma_buf_fd() doivent être convertis pour utiliser l'API dma-buf intégrée au noyau avec dma_buf_get() .
Futures pauses Ion ABI
Avant qu'Ion puisse être déplacé hors de l'arborescence intermédiaire, les futures versions du noyau devront peut-être à nouveau casser l'ABI d'Ion. L'équipe des systèmes Android ne s'attend pas à ce que ces changements affectent les appareils lancés avec la prochaine version d'Android, mais ces changements peuvent affecter les appareils lancés avec les versions ultérieures d'Android.
Par exemple, la communauté en amont a proposé de diviser le nœud unique /dev/ion en plusieurs nœuds par tas (par exemple, /dev/ion/heap0 ) pour permettre aux appareils d'appliquer différentes politiques SELinux à chaque tas. Si ce changement est implémenté dans une future version du noyau, cela briserait Ion ABI.
Les appareils livrés avec le noyau 4.14 et supérieur sont affectés par une refactorisation majeure du module du noyau Ion , que de nombreuses implémentations de couche d'abstraction matérielle (HAL) d'allocateur de mémoire graphique (gralloc) de fournisseurs appellent pour allouer des tampons de mémoire partagée. Cet article fournit des conseils sur la migration du code du fournisseur existant vers la nouvelle version d'Ion et discute des futures ruptures possibles de l'interface binaire d'application (ABI).
À propos de Ion
Ion fait partie de l' arborescence intermédiaire des travaux en cours du noyau en amont. Pendant la phase de préparation, l'ABI espace utilisateur-noyau d'Ion peut être interrompu entre les principales versions du noyau. Bien que les ruptures d'Ion ABI n'affectent pas directement les applications ordinaires ou les appareils déjà lancés , les fournisseurs migrant vers de nouvelles versions majeures du noyau peuvent rencontrer des changements qui affectent le code du fournisseur appelant dans Ion. De plus, de futures ruptures d'ABI pourraient survenir lorsque l'équipe des systèmes Android travaillera en amont pour déplacer Ion hors de l'arborescence intermédiaire.
Changements dans Android-4.14
Le noyau 4.12 a fortement refactorisé le code du noyau Ion, nettoyant et supprimant les parties d'Ion qui chevauchaient avec d'autres frameworks du noyau. En conséquence, de nombreux ioctls Ion existants ne sont plus pertinents et ont été supprimés.
Suppression des clients et des poignées Ion
Avant le noyau 4.12, l'ouverture /dev/ion allouait un client Ion . L'ioctl ION_IOC_ALLOC a alloué un nouveau tampon et l'a renvoyé à l'espace utilisateur en tant que handle Ion (un entier opaque significatif uniquement pour le client Ion qui l'a alloué). Pour mapper les tampons dans l'espace utilisateur ou les partager avec d'autres processus, les descripteurs Ion ont été réexportés en tant que fds dma-buf à l'aide de l'ioctl ION_IOC_SHARE .
Dans le noyau 4.12, l'ioctl ION_IOC_ALLOC génère directement les fds dma-buf. L’état intermédiaire du handle Ion a été supprimé, ainsi que tous les ioctls qui consomment ou produisent des handles Ion. Étant donné que les fds dma-buf ne sont pas liés à des clients Ion spécifiques, l'ioctl ION_IOC_SHARE n'est plus nécessaire et toute l'infrastructure client Ion a été supprimée.
Ajout d'ioctls de cohérence de cache
Avant le noyau 4.12, Ion fournissait un ioctl ION_IOC_SYNC pour synchroniser le descripteur de fichier avec la mémoire. Cet ioctl était mal documenté et peu flexible. En conséquence, de nombreux fournisseurs ont implémenté des ioctls personnalisés pour effectuer la maintenance du cache.
Le noyau 4.12 a remplacé ION_IOC_SYNC par l' DMA_BUF_IOCTL_SYNC ioctl défini dans linux/dma-buf.h . Appelez DMA_BUF_IOCTL_SYNC au début et à la fin de chaque accès CPU, avec des indicateurs spécifiant si ces accès sont des lectures et/ou des écritures. Bien que DMA_BUF_IOCTL_SYNC soit plus détaillé que ION_IOC_SYNC , il donne à l'espace utilisateur plus de contrôle sur les opérations de maintenance du cache sous-jacentes.
DMA_BUF_IOCTL_SYNC fait partie de l'ABI stable du noyau et est utilisable avec tous les fds dma-buf, qu'ils aient été alloués ou non par Ion.
Migration du code du fournisseur vers Android-4.12+
Pour les clients de l'espace utilisateur , l'équipe des systèmes Android encourage fortement l'utilisation de libion plutôt que les appels ioctl() à codage ouvert. Depuis Android 9, Libion détecte automatiquement l'Ion ABI au moment de l'exécution et tente de masquer toute différence entre les noyaux. Cependant, toutes les fonctions Libion qui ont produit ou consommé des handles ion_user_handle_t ne fonctionnent plus après le noyau 4.12. Vous pouvez remplacer ces fonctions par les opérations équivalentes suivantes sur dma-buf fds, qui fonctionnent sur toutes les versions du noyau à ce jour.
| Appel ion_user_handle_t hérité | Appel dma-buf fd équivalent |
|---|---|
ion_alloc(ion_fd, …, &buf_handle) | ion_alloc_fd(ion_fd, ..., &buf_fd) |
ion_share(ion_fd, buf_handle, &buf_fd) | N/A (cet appel n'est pas nécessaire avec dma-buf fds) |
ion_map(ion_fd, buf_handle, ...) | mmap(buf_fd, ...) |
ion_free(ion_fd, buf_handle) | close(buf_fd) |
ion_import(ion_fd, buf_fd, &buf_handle) | N/A (cet appel n'est pas nécessaire avec dma-buf fds) |
ion_sync_fd(ion_fd, buf_fd) | If (ion_is_legacy(ion_fd)) |
Pour les clients intégrés au noyau , étant donné qu'Ion n'exporte plus d'API orientées noyau, les pilotes qui utilisaient auparavant l'API du noyau Ion intégrée au noyau avec ion_import_dma_buf_fd() doivent être convertis pour utiliser l'API dma-buf intégrée au noyau avec dma_buf_get() .
Futures pauses Ion ABI
Avant qu'Ion puisse être déplacé hors de l'arborescence intermédiaire, les futures versions du noyau devront peut-être à nouveau casser l'ABI d'Ion. L'équipe des systèmes Android ne s'attend pas à ce que ces changements affectent les appareils lancés avec la prochaine version d'Android, mais ces changements peuvent affecter les appareils lancés avec les versions ultérieures d'Android.
Par exemple, la communauté en amont a proposé de diviser le nœud unique /dev/ion en plusieurs nœuds par tas (par exemple, /dev/ion/heap0 ) pour permettre aux appareils d'appliquer différentes politiques SELinux à chaque tas. Si ce changement est implémenté dans une future version du noyau, cela briserait Ion ABI.