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:
- Compila el kernel y su representación de ABI.
- Analiza las diferencias de las ABI entre la compilación y una referencia.
- Actualiza la representación de ABI (si es necesario).
- Trabaja con listas de símbolos.
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.
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 elCONFIG
que se usa para#ifdef
esté inhabilitado en el defconfig de producción ygki_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:
Espera a recibir un código +2 de revisión de código para el conjunto de parches.
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 entask_struct
ymm_event_count
Este parche también actualiza la enummm_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 incluirCONFIG_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
enstruct device
. Este campo DEBE ser opaco para los módulos, de modo que no puedan realizar cambios en campos dedevice->fw_node
o hacer suposiciones sobre su tamaño.Sin embargo, si un módulo incluye
<linux/fwnode.h>
(directa o indirectamente), el campofwnode
enstruct device
ya no es opaco. El módulo puede realizar cambios endevice->fwnode->dev
odevice->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 defwnode
), 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
. ConsultaKBUILD_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 marcaKBUILD_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 elstruct 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>
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.