A partir del 27 de marzo de 2025, te recomendamos que uses android-latest-release en lugar de aosp-main para compilar y contribuir a AOSP. Para obtener más información, consulta Cambios en AOSP.

Se usó la API de Cloud Translation para traducir esta página.

Supervisión de ABI de kernel de Android
Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Puedes usar las herramientas de supervisión de la interfaz binaria de aplicación (ABI), disponibles en Android 11 y versiones posteriores, para estabilizar la ABI de kernel de los kernels de Android. Las herramientas recopilan y comparan representaciones de ABI a partir de objetos binarios de kernel existentes (más de vmlinux módulos de GKI). Estas ABI son los archivos .stg y las listas de símbolos. La interfaz en la que la representación proporciona una vista se denomina interfaz del módulo de kernel. (KMI). Puedes usar las herramientas para realizar un seguimiento de los cambios y mitigarlos en el KMI.

Las herramientas de supervisión de ABI se desarrollan en AOSP y usan STG (o libabigail en Android 13 y versiones anteriores) para generar y comparar representaciones.

En esta página, se describen las herramientas, el proceso de recopilación y análisis de las representaciones de ABI, y el uso de esas representaciones para proporcionar estabilidad a la ABI en el kernel. En esta página, también se proporciona información para contribuir a cambios con los kernels de Android.

Proceso

El análisis de la ABI del kernel requiere varios pasos, la mayoría de los cuales se pueden automatizar:

Las siguientes instrucciones funcionan para cualquier kernel que puedas compilar con una cadena de herramientas compatible (como la cadena de herramientas de Clang precompilada). repo manifests están disponibles para todas las ramas de kernel común de Android y para varias específicos del dispositivo, garantizan que se use la cadena de herramientas correcta cuando compilar una distribución de kernel para el análisis.

Listas de símbolos

El KMI no incluye todos los símbolos del kernel ni siquiera los más de 30,000 símbolos exportados. En cambio, los símbolos que pueden usar los módulos de los proveedores son se enumeran explícitamente en un conjunto de archivos de lista de símbolos que se mantienen públicamente en la raíz del árbol del kernel. La unión de todos los símbolos en todos los archivos de lista de símbolos define el conjunto de símbolos de KMI que se mantienen como estables. Un ejemplo de archivo de lista de símbolos es abi_gki_aarch64_db845c, que declara los símbolos necesarios para la DragonBoard 845c.

Solo los símbolos enumerados en una lista de símbolos y sus estructuras relacionadas y se consideran parte del KMI. Puedes publicar cambios en tus listas de símbolos si no están presentes los símbolos que necesitas. Después de que las nuevas interfaces una lista de símbolos y que son parte de la descripción del KMI, se mantienen como estables y no debe quitarse de la lista de símbolos ni modificarse después de que se sin congelar.

Cada rama del kernel de KMI del kernel común de Android (ACK) tiene su propio conjunto de listas de símbolos. No se intenta proporcionar estabilidad de ABI entre diferentes ramas del kernel de KMI. Por ejemplo, el KMI de android12-5.10 es completamente independiente del KMI de android13-5.10.

Las herramientas de ABI usan listas de símbolos de KMI para limitar qué interfaces se deben supervisar para verificar su estabilidad. El lista de símbolos principales contiene los símbolos que requieren los módulos del kernel de GKI. Se espera que los proveedores envíen y actualicen listas de símbolos adicionales para garantizar que las interfaces de las que dependen mantengan la compatibilidad con la ABI. Por ejemplo, para ver una lista de listas de símbolos para el android13-5.15, consulta https://android.googlesource.com/kernel/common/+/refs/heads/android13-5.15/android

Una lista de símbolos contiene los símbolos informados como necesarios para el estado proveedor o dispositivo. La lista completa que usan las herramientas es la unión de todos los Archivos de lista de símbolos de KMI. Las herramientas de ABI determinan los detalles de cada símbolo, incluidas las siguientes: la firma de función y las estructuras de datos anidadas.

Cuando el KMI está inmovilizado, no se permiten cambios en las interfaces de KMI existentes. sean estables. Sin embargo, los proveedores pueden agregar símbolos al KMI en cualquier momento, siempre que las incorporaciones no afecten la estabilidad de la ABI existente. Agregados recientemente se mantienen tan estables en cuanto se citan con una lista de símbolos KMI. Los símbolos no se deben quitar de la lista de un kernel, a menos que se pueda confirmar. que nunca se envió ningún dispositivo que dependa de ese símbolo.

Puedes generar una lista de símbolos de KMI para un dispositivo con las instrucciones de Cómo trabajar con listas de símbolos. Muchos socios envían una lista de símbolos por ACK, pero esto no es un requisito estricto. Si se necesita ayuda con el mantenimiento, puedes enviar varias listas de símbolos.

Extiende el KMI

Mientras que los símbolos de KMI y las estructuras relacionadas se mantienen estables (lo que significa cambios que rompen interfaces estables en un kernel con KMI inmovilizado no se pueden el kernel de GKI permanece abierto a extensiones para que los dispositivos que se envían no necesitan definir todas sus dependencias antes de que el KMI sin congelar. Para extender el KMI, puedes agregar símbolos nuevos al KMI para valores nuevos funciones de kernel exportadas existentes, incluso si el KMI está bloqueado. También se pueden aceptar parches de kernel nuevos si no dañan el KMI.

Información acerca de las fallas de KMI

Un kernel tiene fuentes, y los objetos binarios se compilan a partir de esas fuentes. Las ramas de kernel supervisadas por ABI incluyen una representación de ABI del GKI actual. ABI (en forma de archivo .stg). Después de los objetos binarios (vmlinux, Image y módulos de GKI), se puede extraer una representación de ABI de la binarios. Cualquier cambio que se realice en el archivo de origen del kernel puede afectar los objetos binarios y también afectarán al elemento .stg extraído. El analizador AbiAnalyzer compara el archivo .stg confirmado con el que se extrae de los artefactos de compilación y establece una etiqueta de lint-1 en el cambio en Gerrit si encuentra una diferencia semántica.

Controla las rupturas de ABI

A modo de ejemplo, el siguiente parche introduce una ruptura de ABI muy obvia:

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 42786e6364ef..e15f1d0f137b 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -657,6 +657,7 @@ struct mm_struct {
                ANDROID_KABI_RESERVE(1);
        } __randomize_layout;

+       int tickle_count;
        /*
         * The mm_cpumask needs to be at the end of mm_struct, because it
         * is dynamically sized based on nr_cpu_ids.

Cuando ejecutes la ABI de compilación con este parche aplicado, las herramientas se cierran con un código de error distinto de cero e informa una diferencia de ABI similar a la siguiente:

function symbol 'struct block_device* I_BDEV(struct inode*)' changed
  CRC changed from 0x8d400dbd to 0xabfc92ad

function symbol 'void* PDE_DATA(const struct inode*)' changed
  CRC changed from 0xc3c38b5c to 0x7ad96c0d

function symbol 'void __ClearPageMovable(struct page*)' changed
  CRC changed from 0xf489e5e8 to 0x92bd005e

... 4492 omitted; 4495 symbols have only CRC changes

type 'struct mm_struct' changed
  byte size changed from 992 to 1000
  member 'int tickle_count' was added
  member 'unsigned long cpu_bitmap[0]' changed
    offset changed by 64

Se detectaron diferencias de ABI en el tiempo de compilación

El motivo más común de errores es que el controlador usa un símbolo nuevo del que no está en ninguna de las listas de símbolos.

Si el símbolo no se incluye en la lista de símbolos (android/abi_gki_aarch64), primero debes verificar que se exporte con EXPORT_SYMBOL_GPL(symbol_name) y, luego, actualizar la representación XML de ABI y la lista de símbolos. Por ejemplo, los siguientes cambios agregan la nueva función de FS incremental a la rama android-12-5.10, que incluye la actualización de la lista de símbolos y la representación XML de ABI.

El ejemplo de cambio de función está en (aosp/1345659).
El ejemplo de la lista de símbolos se encuentra en aosp/1346742.
El ejemplo de cambio de XML de ABI se encuentra en aosp/1349377.

Si el símbolo se exporta (ya sea que lo hayas hecho tú o se haya exportado anteriormente), pero ningún otro controlador lo usa, es posible que obtengas un error de compilación similar al siguiente.

Comparing the KMI and the symbol lists:
+ build/abi/compare_to_symbol_list out/$BRANCH/common/Module.symvers out/$BRANCH/common/abi_symbollist.raw
ERROR: Differences between ksymtab and symbol list detected!
Symbols missing from ksymtab:
Symbols missing from symbol list:
 - simple_strtoull

Para resolverlo, actualiza la lista de símbolos de KMI en el kernel y en el ACK (consulta Cómo actualizar la representación de ABI). Para ver un ejemplo de cómo actualizar el XML de la ABI y la lista de símbolos en el ACK, consulta aosp/1367601.

Cómo resolver fallas de ABI de kernel

Puedes manejar las fallas de ABI del kernel si refactorizas el código para no cambiar la ABI o la actualización de la representación de ABI. Usa el siguiente diagrama para determinar el mejor enfoque para tu situación.

Diagrama de flujo de la ruptura de ABI

Figura 1: Resolución de fallas de ABI

Cómo refactorizar código para evitar cambios en la ABI

Haz todo lo posible para evitar modificar la ABI existente. En muchos casos, puedes refactorizar tu código para quitar los cambios que afectan a la ABI.

Refactoriza los cambios en los campos de struct. Si un cambio modifica la ABI de una depuración atributo, agrega una #ifdef alrededor de los campos (en los structs y el código fuente referencias) y asegúrate de que el CONFIG que se usa para #ifdef esté inhabilitado en el defconfig de producción y gki_defconfig. Para ver un ejemplo de cómo se puede agregar una configuración de depuración a una estructura sin romper la ABI, consulta este conjunto de parches.
Refactorización de funciones para no cambiar el kernel principal Si las nuevas funciones necesitan se agregará a ACK para admitir los módulos de socios, intenta refactorizar la ABI parte del cambio para evitar modificar la ABI del kernel. Para ver un ejemplo de uso la ABI de kernel existente para agregar capacidades adicionales sin cambiar la ABI de kernel se refieren a (aosp/1312213).

Cómo corregir una ABI dañada en Android Gerrit

Si no rompiste la ABI del kernel de forma intencional, debes investigar con la guía que proporcionan las herramientas de supervisión de ABI. La más común Las causas de las fallas son las estructuras de datos modificadas y el símbolo asociado CRC. cambios, o debido a cambios en las opciones de configuración que ocasionen cualquiera de los mencionados. Comienza por abordar los problemas que encontró la herramienta.

Para reproducir los hallazgos de ABI de forma local, consulta Compila el kernel y su representación de ABI.

Información acerca de las etiquetas de Lint-1

Si subes cambios a una rama que contiene un KMI congelado o finalizado, los cambios deben pasar la AbiAnalyzer para garantizar que no afecten la ABI estable de manera incompatible. Durante este proceso, AbiAnalyzer busca informe de ABI que se crea durante la compilación (una compilación extendida que realiza las compilación normal y, luego, algunos pasos de extracción y comparación de ABI.

Si AbiAnalyzer encuentra un informe no vacío, establece la etiqueta Lint-1 y se bloquea el envío del cambio hasta que se resuelva, hasta que el conjunto de parches reciba una etiqueta Lint+1.

Actualiza la ABI del kernel

Si no se puede evitar modificar la ABI, debes aplicar los cambios de código, la representación de la ABI y la lista de símbolos al ACK. Para que lint quite el -1 y no rompa la compatibilidad con GKI, sigue estos pasos:

Sube los cambios de código al ACK.
Espera a recibir una revisión de código de +2 para el conjunto de parches.
Actualiza la representación de ABI de referencia.
Combina los cambios de tu código con el cambio de actualización de ABI.

Sube los cambios de código de ABI a ACK

La actualización de la ABI de ACK depende del tipo de cambio que se realice.

Si un cambio de ABI está relacionado con una función que afecta las pruebas de CTS o VTS, por lo general, el cambio se puede elegir para confirmarlo tal como está. Por ejemplo:
- Se necesita aosp/1289677 para que funcione el audio.
- (aosp/1295945). para que funcione el USB.
Si un cambio de ABI es para una función que se puede compartir con el ACK, ese cambio se puede elegir para ACK tal como está. Por ejemplo, los siguientes cambios no son necesarios para la prueba de CTS o VTS, pero se pueden compartir con ACK:
- (aosp/1250412). es un cambio de atributos térmicos.
- aosp/1288857 es un cambio de EXPORT_SYMBOL_GPL.
Si un cambio de ABI introduce una función nueva que no es necesario incluir en el ACK, puedes introducir los símbolos en el ACK con un stub, como se describe en la siguiente sección.

Usa stubs para ACK

Los stubs solo deben ser necesarios para los cambios del kernel principal que no beneficien al ACK, como cambios de rendimiento y energía. En la siguiente lista, se detallan ejemplos de stubs y selecciones parciales en ACK para GKI.

stub de la función de aislamiento de núcleo (aosp/1284493). Las capacidades en ACK no son necesarias, pero los símbolos deben estar presentes en ACK para que tus módulos los usen.
Símbolo de marcador de posición para el módulo de proveedores (aosp/1288860).
Selección especial de solo ABI de la función de seguimiento de eventos de mm por proceso (aosp/1288454). El parche original se seleccionó para ACK y, luego, se recortó para incluir solo los cambios necesarios para resolver la diferencia de ABI para task_struct y mm_event_count. Este parche también actualiza la enumeración mm_event_type para que contenga los miembros finales.
Selección parcial de cambios de ABI de struct térmico que requerían más que solo agregar los nuevos campos de ABI.
- El parche aosp/1255544 resolvió las diferencias de ABI entre el kernel del socio y el ACK.
- Aplicar parche (aosp/1291018). Se solucionaron los problemas funcionales detectados durante la prueba de GKI del parche anterior. La corrección incluyó la inicialización de la estructura del parámetro del sensor para registrar varias zonas térmicas en un solo sensor.
Cambios en la ABI de CONFIG_NL80211_TESTMODE (aosp/1344321). Este parche agregó los cambios de struct necesarios para ABI y aseguró de que campos adicionales no causaron diferencias funcionales, lo que permitió que los socios incluir CONFIG_NL80211_TESTMODE en sus kernels de producción y seguir mantener el cumplimiento de GKI.

Aplica el KMI durante el tiempo de ejecución

Los kernels de GKI usan las opciones de configuración TRIM_UNUSED_KSYMS=y y UNUSED_KSYMS_WHITELIST=<union of all symbol lists>, que limitan los símbolos exportados (como los símbolos exportados con EXPORT_SYMBOL_GPL()) a los que aparecen en una lista de símbolos. Todos los demás símbolos no se exportan, y se rechaza la carga de un módulo que requiera un símbolo no exportado. Esta restricción se aplica en el tiempo de compilación y se marcan las entradas faltantes.

Para fines de desarrollo, puedes usar una compilación del kernel de GKI que no incluye recorte de símbolos (es decir, se pueden usar todos los símbolos que generalmente se exportan). Para ubicar estas compilaciones, busca las compilaciones kernel_debug_aarch64 en ci.android.com

Aplica de manera forzosa el KMI mediante el control de versiones de módulos

Los kernels de la imagen genérica del kernel (GKI) usan el control de versiones de módulos. (CONFIG_MODVERSIONS) como medida adicional para aplicar el cumplimiento de KMI en tiempo de ejecución. El control de versiones de los módulos puede causar discrepancias en la verificación de redundancia cíclica (CRC) fallas en el tiempo de carga del módulo si el KMI esperado de un módulo no coincide con vmlinux de KMI. Por ejemplo, la siguiente es una falla típica que ocurre en El tiempo de carga del módulo debido a una discrepancia en la CRC para el símbolo module_layout():

init: Loading module /lib/modules/kernel/.../XXX.ko with args ""
XXX: disagrees about version of symbol module_layout
init: Failed to insmod '/lib/modules/kernel/.../XXX.ko' with args ''

Usos del control de versiones de módulos

El control de versiones de módulos es útil por los siguientes motivos:

El control de versiones de módulos detecta cambios en la visibilidad de la estructura de datos. Módulos if cambian estructuras de datos opacas, es decir, las estructuras de datos que no forman parte del KMI, se rompen después de futuros cambios en la estructura.

A modo de ejemplo, considera la fwnode en struct device. Este campo DEBE ser opaco para los módulos, de modo que no puedan realizar cambios en campos de device->fw_node o hacer suposiciones sobre su tamaño.

Sin embargo, si un módulo incluye <linux/fwnode.h> (directa o indirectamente), el campo fwnode en struct device ya no es opaco. El módulo puede realizar cambios en device->fwnode->dev o device->fwnode->ops Esta situación es problemática por varias razones, se indica de la siguiente manera:
- Puede romper las suposiciones que el código principal del kernel hace sobre su base de datos interna. las estructuras de datos.
- Si una actualización futura del kernel cambia el struct fwnode_handle (el tipo de datos de fwnode), el módulo ya no funcionará con el kernel nuevo. Además, stgdiff no mostrará diferencias porque el módulo falla el KMI manipulando directamente estructuras internas de datos de maneras que no se puede capturarse solo inspeccionando la representación binaria.
Un módulo actual se considera incompatible con KMI cuando se carga en una fecha posterior. por un nuevo kernel incompatible. El control de versiones de módulos agrega una verificación de tiempo de ejecución para evitar cargar accidentalmente un módulo que no sea compatible con el KMI del kernel. Esta comprobación evita problemas de tiempo de ejecución difíciles de depurar y fallas del kernel que podrían resultado de una incompatibilidad no detectada en el KMI.

Habilitar el control de versiones de módulos evita todos estos problemas.

Cómo verificar si hay discrepancias de CRC sin iniciar el dispositivo

stgdiff compara e informa las discrepancias de CRC entre los kernels junto con otros Diferencias de ABI

Además, una compilación de kernel completa con CONFIG_MODVERSIONS habilitado genera un archivo Module.symvers como parte del proceso de compilación normal. Este archivo tiene uno línea para cada símbolo exportado por el kernel (vmlinux) y los módulos. Cada línea consiste en el valor de CRC, el nombre del símbolo, el espacio de nombres del símbolo, el vmlinux o el nombre del módulo que exporta el símbolo y el tipo de exportación (por ejemplo, EXPORT_SYMBOL en comparación con EXPORT_SYMBOL_GPL).

Puedes comparar los archivos Module.symvers entre la compilación de GKI y tu compilación. para comprobar si hay diferencias de CRC en los símbolos exportados por vmlinux. Si hay una diferencia en el valor de CRC en cualquier símbolo exportado por vmlinux y ese símbolo es usado por uno de los módulos que cargas en tu dispositivo, el módulo no se carga.

Si no tienes todos los artefactos de compilación, pero sí los archivos vmlinux de entre el kernel de GKI y su kernel, puede comparar los valores de CRC de un determinado ejecutando el siguiente comando en ambos kernels y comparando los Resultado:

nm <path to vmlinux>/vmlinux | grep __crc_<symbol name>

Por ejemplo, el siguiente comando verifica el valor de CRC del símbolo module_layout:

nm vmlinux | grep __crc_module_layout
0000000008663742 A __crc_module_layout

Cómo resolver discrepancias de CRC

Sigue estos pasos para resolver una discrepancia de CRC cuando se carga un módulo:

Compila el kernel de GKI y el kernel de tu dispositivo con --kbuild_symtypes. como se muestra en el siguiente comando:
```
tools/bazel run --kbuild_symtypes //common:kernel_aarch64_dist
```
Con este comando, se genera un archivo .symtypes para cada archivo .o. Consulta KBUILD_SYMTYPES en Kleaf para conocer los detalles.

Para Android 13 y versiones anteriores, compila el kernel de GKI. y el kernel de tu dispositivo. Para ello, antepone KBUILD_SYMTYPES=1 al comando que usar para compilar el kernel, como se muestra en el siguiente comando:
```
KBUILD_SYMTYPES=1 BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
```
Cuando usas build_abi.sh,, la marca KBUILD_SYMTYPES=1 ya se configuró de forma implícita.

Busca el archivo .c en el que se exporta el símbolo con discrepancia de CRC con el siguiente comando:

cd common && git grep EXPORT_SYMBOL.*module_layout
kernel/module.c:EXPORT_SYMBOL(module_layout);

El archivo .c tiene un archivo .symtypes correspondiente en GKI, y tu archivo artefactos de compilación del kernel del dispositivo. Para ubicar el archivo .c, usa los siguientes comandos:
```
cd out/$BRANCH/common && ls -1 kernel/module.*
kernel/module.o
kernel/module.o.symversions
kernel/module.symtypes
```
Las siguientes son las características del archivo .c:
- El formato del archivo .c es una línea (potencialmente muy larga) por símbolo.
- [s|u|e|etc]# al comienzo de la línea significa que el símbolo es de tipo de datos. [struct|union|enum|etc] Por ejemplo:
```
t#bool typedef _Bool bool
```
- Si falta el prefijo # al comienzo de la línea, se indica que el símbolo es una función. Por ejemplo:
```
find_module s#module * find_module ( const char * )
```
Compara los dos archivos y corrige todas las diferencias.

Caso 1: Diferencias debido a la visibilidad del tipo de datos

Si un kernel mantiene un símbolo o un tipo de datos opaco para los módulos y el otro kernel no lo hace, esa diferencia aparece entre los archivos .symtypes de los dos kernels. El archivo .symtypes de uno de los kernels tiene UNKNOWN. para un símbolo y el archivo .symtypes del otro kernel tiene una vista expandida del símbolo o del tipo de datos.

Por ejemplo, agregar la siguiente línea al archivo include/linux/device.h en el kernel causa discrepancias de CRC, una de las cuales es para module_layout():

 #include <linux/fwnode.h>

Cuando se compara el module.symtypes de ese símbolo, se expone lo siguiente diferencias:

 $ diff -u <GKI>/kernel/module.symtypes <your kernel>/kernel/module.symtypes
  --- <GKI>/kernel/module.symtypes
  +++ <your kernel>/kernel/module.symtypes
  @@ -334,12 +334,15 @@
  ...
  -s#fwnode_handle struct fwnode_handle { UNKNOWN }
  +s#fwnode_reference_args struct fwnode_reference_args { s#fwnode_handle * fwnode ; unsigned int nargs ; t#u64 args [ 8 ] ; }
  ...

Si tu kernel tiene el valor UNKNOWN y el kernel de GKI tiene la vista expandida del símbolo (muy improbable), luego combina el último kernel común de Android en tu kernel para que uses la base de kernel de GKI más reciente.

En la mayoría de los casos, el kernel de GKI tiene un valor de UNKNOWN, pero tu kernel tiene el valor de detalles internos del símbolo debido a los cambios realizados en el kernel. Esto se debe a que uno de los archivos de tu kernel agregó un #include que no está presente en el kernel de GKI.

A menudo, la solución es simplemente ocultar el nuevo #include de genksyms.

#ifndef __GENKSYMS__
#include <linux/fwnode.h>
#endif

De lo contrario, para identificar el #include que causa la diferencia, sigue estos pasos:

Abre el archivo de encabezado que define el símbolo o el tipo de datos que tiene esta diferencia. Por ejemplo, edita include/linux/fwnode.h para el struct fwnode_handle.
Agrega el siguiente código en la parte superior del archivo de encabezado:
```
#ifdef CRC_CATCH
#error "Included from here"
#endif
```
En el archivo .c del módulo que tiene una discrepancia de CRC, agrega el elemento siguiente como la primera línea antes de cualquiera de las líneas de #include.
```
#define CRC_CATCH 1
```

Compila tu módulo. El error de tiempo de compilación resultante muestra la cadena de #include del archivo de encabezado que generó esta discrepancia de CRC. Por ejemplo:

In file included from .../drivers/clk/XXX.c:16:`
In file included from .../include/linux/of_device.h:5:
In file included from .../include/linux/cpu.h:17:
In file included from .../include/linux/node.h:18:
.../include/linux/device.h:16:2: error: "Included from here"
#error "Included from here"

Uno de los vínculos de esta cadena de #include se debe a un cambio que se realizó en la que falta en el kernel de GKI.

Identifica el cambio, reviertelo en tu kernel o súbelo a ACK y haz que se combine.

Caso 2: Diferencias debido a cambios en el tipo de datos

Si la discrepancia en la CRC para un símbolo o un tipo de datos no se debe a una diferencia en visibilidad, se debe a cambios reales (adiciones, eliminaciones o cambios) en el tipo de datos en sí.

Por ejemplo, si realizas el siguiente cambio en tu kernel, se generarán varias CRC. hay discrepancias, ya que muchos símbolos se ven afectados indirectamente por este tipo de cambio:

diff --git a/include/linux/iommu.h b/include/linux/iommu.h
  --- a/include/linux/iommu.h
  +++ b/include/linux/iommu.h
  @@ -259,7 +259,7 @@ struct iommu_ops {
     void (*iotlb_sync)(struct iommu_domain *domain);
     phys_addr_t (*iova_to_phys)(struct iommu_domain *domain, dma_addr_t iova);
     phys_addr_t (*iova_to_phys_hard)(struct iommu_domain *domain,
  -        dma_addr_t iova);
  +        dma_addr_t iova, unsigned long trans_flag);
     int (*add_device)(struct device *dev);
     void (*remove_device)(struct device *dev);
     struct iommu_group *(*device_group)(struct device *dev);

Una discrepancia de CRC es para devm_of_platform_populate().

Si comparas los archivos .symtypes de ese símbolo, es posible que se vean de la siguiente manera:

 $ diff -u <GKI>/drivers/of/platform.symtypes <your kernel>/drivers/of/platform.symtypes
  --- <GKI>/drivers/of/platform.symtypes
  +++ <your kernel>/drivers/of/platform.symtypes
  @@ -399,7 +399,7 @@
  ...
  -s#iommu_ops struct iommu_ops { ... ; t#phy
  s_addr_t ( * iova_to_phys_hard ) ( s#iommu_domain * , t#dma_addr_t ) ; int
    ( * add_device ) ( s#device * ) ; ...
  +s#iommu_ops struct iommu_ops { ... ; t#phy
  s_addr_t ( * iova_to_phys_hard ) ( s#iommu_domain * , t#dma_addr_t , unsigned long ) ; int ( * add_device ) ( s#device * ) ; ...

Para identificar el tipo modificado, sigue estos pasos:

Busca la definición del símbolo en el código fuente (por lo general, en los archivos .h).
- Para las diferencias de símbolos entre tu kernel y el kernel de GKI, utiliza este código: Ejecuta el siguiente comando para encontrar la confirmación:
```
git blame
```
- En el caso de los símbolos borrados (cuando se borra un símbolo en un árbol y también deseas borrarlo en el otro árbol), debes encontrar el cambio que borra la línea. Usa el siguiente comando en el árbol donde se borró la línea:
```
git log -S "copy paste of deleted line/word" -- <file where it was deleted>
```
Nota: No copies y pegues pestañas.
Revisa la lista de confirmaciones que se muestra para ubicar el cambio o la eliminación. Es probable que la primera confirmación sea la que buscas. Si no es así, revisa la lista hasta encontrar la confirmación.
Después de que identifiques el cambio, puedes revertirlo en tu kernel o subirlo a ACK y obtenerlo combinadas.