Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

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

Supervisión de ABI de kernel de Android

Puedes usar las herramientas de supervisión de la interfaz binaria de la aplicación (ABI), disponibles en Android 11 y versiones posteriores, para estabilizar el kernel ABI de 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 son desarrollados en AOSP y utiliza STG (o libabigail in Android 13 y versiones anteriores) para generar y comparar de datos.

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

Proceso

Analizar la ABI del kernel requiere varios pasos, la mayoría de los cuales pueden automatizarse:

Las siguientes instrucciones funcionan para cualquier kernel que puedes crear con un de la cadena de herramientas compatible (como la cadena de herramientas de Clang compilada previamente). 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 los más de 30,000 caracteres. 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. Ejemplo de un archivo de lista de símbolos es abi_gki_aarch64_db845c que declara los símbolos necesarios para el 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 tu listas de símbolos si los símbolos que necesitas no están presentes. 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 KMI del kernel común de Android (ACK) tiene su propio conjunto de símbolos. listas. No se intenta proporcionar estabilidad de la ABI entre diferentes kernel de KMI. ramas. Por ejemplo, el KMI para android12-5.10 es completamente independiente de el KMI de android13-5.10.

Las herramientas de ABI usan listas de símbolos de KMI para limitar las interfaces que deben supervisarse. la estabilidad. El lista de símbolos principales contiene los símbolos que requieren los módulos del kernel de GKI. Los proveedores son se espera que envíes y actualices listas de símbolos adicionales para garantizar que el las interfaces de las que se basan mantendrán la compatibilidad con 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 del KMI para un dispositivo usando las instrucciones de Cómo trabajar con listas de símbolos. Muchos socios envían una lista de símbolos por cada ACK, pero este no es un requisito obligatorio. 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. Nuevo kernel o parches si no rompen 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 de AbiAnalyzer compara archivo .stg confirmado con el que se extrae de los artefactos de compilación y establece un Etiqueta de lint-1 en el cambio en Gerrit si encuentra una diferencia semántica.

Cómo controlar las fallas de ABI

A modo de ejemplo, el siguiente parche introduce una falla 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 durante la 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 está incluido en la lista de símbolos (android/abi_gki_aarch64), haz lo siguiente: primero debes verificar que se exportó con EXPORT_SYMBOL_GPL(symbol_name) y, luego, actualiza la Lista de símbolos y representación XML de ABI. 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 XML de ABI se encuentra en (aosp/1349377).

Si el símbolo se exporta (ya sea por ti o si ya se exportó), pero no lo esté usando otro controlador, es posible que recibas 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 tanto en tu kernel como en el ACK (consulta Actualiza la representación de ABI). Por ejemplo de actualización de la ABI XML 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 los siguientes para determinar el mejor enfoque para tu situación.

Diagrama de flujo de interrupción 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 un proceso config a un struct sin romper la ABI. Consulta esta parcheset.
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 Gerrit de Android

Si no rompiste intencionalmente la ABI del kernel, debes investigar. con la orientación que proporcionan las herramientas de supervisión de ABI. Las más comunes Las causas de las fallas son las estructuras de datos modificadas y el símbolo asociado CRC. cambios en la configuración o debido a cambios en las opciones de configuración que generen cualquiera de los casos mencionados. Primero, aborda los problemas que encontró la herramienta.

Para reproducir los hallazgos de ABI de forma local, consulta la siguiente documentación: 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 el AbiAnalyzer para garantizar que los cambios no afecten la versión estable ABI de forma 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 que no está vacío, establece la etiqueta de Lint-1 y no se podrá enviar el cambio hasta que se resuelva. hasta que el conjunto de parches reciba un Etiqueta de lint+1.

Cómo actualizar la ABI del kernel

Si es inevitable modificar la ABI, deberás aplicar los cambios en el código la representación de ABI y la lista de símbolos al ACK. Para que Lint sea quitar -1 y no interrumpir la compatibilidad con GKI, sigue estos pasos:

Sube los cambios de código al ACK.
Espera a recibir un código +2 de revisión de código 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, el por lo general, se puede elegir con cuidado para ACK tal como está. Por ejemplo:
- (aosp/1289677). necesario para que el audio funcione.
- (aosp/1295945). para que funcione el USB.
Si un cambio de ABI es para una función que se puede compartir con el ACK, el cambio se puede elegir con cuidado 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 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 para 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. La siguiente lista detalla 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 usen estos símbolos.
Símbolo de marcador de posición para el módulo de proveedor (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ó cuidadosamente para ACK y luego se recortó para incluir solo los cambios necesarios para resolver la diferencia de ABI en task_struct y mm_event_count Este parche también actualiza la enum 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.
- Aplicar parche (aosp/1255544). resolvieron las diferencias de ABI entre el kernel del socio y ACK.
- Aplicar parche (aosp/1291018). Se solucionaron los problemas funcionales detectados durante la prueba de GKI del parche anterior. La solución incluyó inicializar la struct del parámetro sensor para registrarla. múltiples zonas térmicas a un solo sensor.
CONFIG_NL80211_TESTMODE cambios en la ABI (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 en 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 símbolos exportados con EXPORT_SYMBOL_GPL()) a los que figuran en un lista de símbolos. Todos los demás símbolos no se exportan, y cargar un módulo requiere una el símbolo no exportado. Esta restricción se aplica en el momento de la compilación y se marcan las entradas que faltan.

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 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 las 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 futura actualización de kernel cambia la struct fwnode_handle (los datos tipo de fwnode), el módulo ya no funcionará con el nuevo kernel. 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 a evita cargar accidentalmente un módulo que no sea compatible con KMI con el 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.

Comprueba si hay discrepancias en la 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 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 contiene el valor de CRC, el nombre del símbolo, el espacio de nombres del símbolo, el vmlinux o nombre del módulo al que se 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 es una diferencia de valor de CRC en cualquier símbolo exportado por vmlinux y que lo usa uno de los módulos que cargas en el dispositivo, el módulo no de carga de trabajo.

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 para el module_layout. símbolo:

nm vmlinux | grep __crc_module_layout
0000000008663742 A __crc_module_layout

Cómo resolver las 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 se establece de forma implícita que ya existe.
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. Usa el siguiente comando para buscar el archivo .c: 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 de una línea (posiblemente 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 opacos para los módulos y el otro 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, si agregas la siguiente línea a la El archivo include/linux/device.h de tu kernel causa discrepancias en 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. Este es porque uno de los archivos de tu kernel agregó un #include que no está presente en el kernel de GKI.

A menudo, la corrección solo oculta 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: pasos:

Abre el archivo de encabezado que define el símbolo o tipo de datos que contiene este la 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 #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, reviértelo en tu kernel o subirlo a ACK y combinarlo.

Caso 2: Diferencias debido a cambios en los tipos 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 para ese símbolo, es posible que se vea 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 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
```
- Para los símbolos eliminados (cuando un símbolo se elimina de un árbol y tú también en el otro árbol), deberás buscar el cambio que borró la línea. Usa el siguiente comando en el árbol donde la línea se borró:
```
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. El primera confirmación es probablemente la que estás buscando. Si no lo es, ve por la lista hasta que encuentres la confirmación.
Después de que identifiques el cambio, puedes revertirlo en tu kernel o subirlo a ACK y obtenerlo combinadas.