Cómo actualizar su kernel de Android a la última versión estable de Linux

nathan @ flashbox ~ / kernels / linux-stable (maestro) $ git log --format =% h v4.4.78..v4.4.121 | wc -l2285 nathan @ flashbox ~ / kernels / linux-stable (maestro) $ git log --format =% h v4.4.78..v4.4.121 arch / arm | wc -l58 nathan @ flashbox ~ / kernels / linux-stable (maestro) $ git log --format =% h v4.4.78..v4.4.121 arch / arm64 | wc -l22 nathan @ flashbox ~ / kernels / linux-stable (maestro) $ git log --format =% h v4.4.78..v4.4.121 fs / ext4 | wc -l18

La parte que lleva más tiempo es la presentación inicial; una vez que esté completamente actualizado, no se necesita tiempo para fusionar en una nueva versión, que generalmente no contiene más de 100 confirmaciones. Sin embargo, los beneficios que esto aporta (más estabilidad y mejor seguridad para sus usuarios) deberían requerir este proceso.

Cómo fusionar el kernel estable de Linux en un kernel de Android

Primero necesita averiguar qué versión de kernel está ejecutando su dispositivo Android.

Por trivial que parezca, es necesario saber por dónde empezar. Ejecute el siguiente comando en su árbol del kernel:

hacer kernelversion

Devolverá la versión en la que se encuentra. Los dos primeros números se usarán para determinar la rama que necesita (por ejemplo, linux-4.4.y para cualquier kernel 4.4) y el último número se usará para determinar qué versión necesita para comenzar con la fusión (por ejemplo, si está en 4.4 .21, fusionará 4.4.22 a continuación).

Obtenga la última fuente del kernel de kernel.org

kernel.org alberga la última fuente del kernel en el repositorio estable de linux . En la parte inferior de esa página, habrá tres enlaces de búsqueda. En mi experiencia, el espejo de Google tiende a ser el más rápido, pero los resultados pueden variar. Ejecute los siguientes comandos:

git remoto agregar linux-estable https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit buscar linux-estable

Decide si quieres fusionar todo el kernel o seleccionar las confirmaciones

A continuación, deberá elegir si desea fusionar las confirmaciones o la selección. Estos son los pros y los contras de cada uno y cuándo es posible que desee realizarlos.

NOTA: Si el código fuente de su kernel está en forma de tarball, lo más probable es que necesite seleccionar, de lo contrario, obtendrá miles de conflictos de archivos porque git está poblando el historial basado puramente en el flujo ascendente, no en lo que el OEM o CAF ha cambiado. Salte al paso 4.

Cosecha de la cereza:

Pros:

• Es más fácil resolver conflictos ya que sabe exactamente qué conflicto está causando un problema.
• Más fácil de reajustar, ya que cada confirmación es independiente.
• Más fácil de bisecar si tiene problemas

Contras:

• Lleva más tiempo ya que cada confirmación debe seleccionarse individualmente.
• Un poco más difícil de saber si el compromiso es desde arriba a primera vista

Vamos

Pros :

• Es más rápido, ya que no tiene que esperar a que se fusionen todos los parches limpios.
• Es más fácil ver cuando una confirmación es desde el origen, ya que usted no será el responsable del compromiso, sino el responsable del mantenimiento.

Contras:

• La resolución de conflictos puede ser un poco más difícil, ya que deberá buscar qué confirmación está causando el conflicto usando git log / git blame, no se lo dirá directamente.
• Rebasar es difícil ya que no se puede reajustar una fusión, ofrecerá seleccionar todas las confirmaciones individualmente. Sin embargo, no debe cambiar la base de datos con frecuencia, en su lugar, use git revert y git merge siempre que sea posible.

Recomendaría hacer una selección selectiva para resolver cualquier problema de conflicto inicialmente, hacer una fusión y luego revertir el problema confirmado después para que la actualización sea más fácil (ya que la fusión es más rápida después de estar actualizada).

Agregue las confirmaciones a su fuente, una versión a la vez

La parte más importante de este proceso es una versión a la vez. PUEDE haber un parche problemático en su serie anterior, que podría causar un problema con el arranque o romper algo como el sonido o la carga (explicado en la sección de consejos y trucos). Hacer cambios de versión incrementales es importante por esta razón, es más fácil encontrar un problema en 50 confirmaciones que en más de 2000 confirmaciones para algunas versiones. Solo recomendaría hacer una fusión completa una vez que conozca todos los problemas comprometidos y las resoluciones de conflictos.

Cosecha de la cereza

Formato:

git cherry-pick ..

Ejemplo:

git cherry-pick v3.10.73..v3.10.74

Vamos

Formato:

ir a fusionar

Ejemplo:

git merge v3.10.74

Recomiendo hacer un seguimiento de los conflictos en las confirmaciones de fusión eliminando los marcadores #.

Cómo resolver conflictos

No podemos ofrecer una guía paso a paso para resolver cada conflicto, ya que implica un buen conocimiento del lenguaje C, pero aquí hay algunas sugerencias.

Si se está fusionando, averigüe qué compromiso está causando el conflicto. Puede hacer esto de dos formas:

1. git log -p v $ (make kernelversion) .. para obtener los cambios entre su versión actual y la última de las versiones anteriores. La bandera -p le dará los cambios realizados por cada confirmación para que pueda ver.
2. Ejecute git blame en el archivo para obtener los hash de cada confirmación en el área. Luego puede ejecutar git show –format = fuller para ver si el confirmador era de mainline / estable, Google o CodeAurora.

• Averigüe si ya tiene el compromiso. Algunos proveedores como Google o CAF intentarán buscar errores críticos, como la solución Dirty COW, y sus backports podrían entrar en conflicto con los de upstream. Puede ejecutar git log –grep = ”” y ver si devuelve algo. Si lo hace, puede omitir la confirmación (si selecciona con precisión usando git reset –hard && git cherry-pick –continuar) o ignorar los conflictos (elimine el<<<<<>>>>>).
• Averigüe si ha habido un backport que está alterando la resolución. A Google y CAF les gusta respaldar ciertos parches que los de Stables no lo harían. Stable a menudo necesitará adaptar la resolución del compromiso de la línea principal a la ausencia de ciertos parches que Google opta por respaldar. Puede ver la confirmación de la línea principal ejecutando git show (el hash de la línea principal estará disponible en el mensaje de confirmación de la confirmación estable). Si hay un backport que lo estropea, puede descartar los cambios o puede usar la versión principal (que es lo que normalmente necesitará hacer).
• Lea lo que intenta hacer la confirmación y vea si el problema ya está solucionado. A veces, CAF puede corregir un error independientemente del upstream, lo que significa que puede sobrescribir su corrección para el upstream o descartarlo, como se indicó anteriormente.

De lo contrario, puede ser solo el resultado de una adición de CAF / Google / OEM, en cuyo caso solo necesita barajar algunas cosas.

Aquí está un espejo del repositorio kernel.org estable de linux en GitHub, que puede ser más fácil para buscar listas de confirmaciones y diferencias para la resolución de conflictos. Recomiendo ir primero a la vista de lista de confirmaciones y localizar el compromiso del problema para ver la diferencia original y compararla con la suya.

URL de ejemplo: https://github.com/nathanchance/linux-stable/commits/linux-3.10.y/arch/arm64/mm/mmu.c

También puede hacerlo a través de la línea de comando:

git log .. git show

Resolver resoluciones tiene que ver con el contexto. Lo que SIEMPRE debe hacer es asegurarse de que su diferencia final coincida con la corriente arriba ejecutando los siguientes comandos en dos ventanas separadas:

git diff HEAD git diff v $ (hacer kernelversion) .. $ (git tag --sort = -taggerdate -l v $ (hacer kernelversion | cut -d. -f 1,2) * | head -n1)

Habilitar rerere

Git tiene una función llamada rerere (que significa Reutilizar resolución grabada), lo que significa que cuando detecta un conflicto, registrará cómo lo resolvió para que pueda reutilizarlo más tarde. Esto es especialmente útil para los rebasadores crónicos con fusión y selección, ya que solo necesitará ejecutar git add. && git: continúe al rehacer la activación ascendente ya que el conflicto se resolverá como lo resolvió anteriormente.

Se puede habilitar ejecutando el siguiente comando en el repositorio de su kernel:

git config rerere.enabled true

Cómo git bisect cuando se ejecuta en un compilador o error en tiempo de ejecución

Dado que agregará una cantidad considerable de confirmaciones, es muy posible que introduzca un compilador o un error de tiempo de ejecución. ¡En lugar de simplemente darse por vencido, puede usar la herramienta de bisección integrada de git para descubrir la causa raíz del problema! Idealmente, estará compilando y mostrando cada versión del kernel a medida que la agrega, por lo que la bisección llevará menos tiempo si es necesario, pero puede bisecar 5000 confirmaciones sin ningún problema.

Lo que hará git bisect es tomar un rango de confirmaciones, desde donde el problema está presente hasta donde no estaba presente, y luego comenzar a reducir a la mitad el rango de confirmación, lo que le permite construir y probar y hacerle saber si es bueno o no. . Continuará esto hasta que escupe la confirmación que causa su problema. En ese momento, puede arreglarlo o revertirlo.

1. Comience a bisecar: git bisect start
2. Etiqueta la revisión actual como mala: git bisect bad
3. Etiquetar una revisión como buena: git bisect good
4. Construir con la nueva revisión
5. Según el resultado (si el problema está presente o no), dígale a git: git bisect good O git bisect bad
6. Enjuague y repita los pasos 4-5 hasta encontrar el compromiso del problema.
7. Revertir o solucionar el problema commit.

NOTA: Las fusiones necesitarán ejecutar temporalmente git rebase -i para aplicar todos los parches a su rama para una bisección adecuada, ya que la bisección con las fusiones en su lugar a menudo hará que se verifiquen las confirmaciones ascendentes, lo que significa que no tiene ninguna de las confirmaciones específicas de Android. Puedo profundizar más en esto si lo solicito, pero créame, es necesario. Una vez que haya identificado la confirmación del problema, puede revertirla o volver a establecerla en la fusión.

NO aplaste las actualizaciones ascendentes

Muchos desarrolladores nuevos se sienten tentados a hacer esto, ya que es 'más limpio' y 'más fácil' de administrar. Esto es terrible por varias razones:

• Se pierde la autoría. Es injusto para otros desarrolladores que se les quite el crédito por su trabajo.
• Bisecar es imposible. Si eliminas una serie de confirmaciones y algo es un problema en esa serie, es imposible saber qué confirmación causó un problema en una falla.
• Las elecciones futuras son más difíciles. Si necesita reajustar con una serie aplastada, es difícil / imposible saber de dónde resulta un conflicto.

Suscríbase a la lista de correo del kernel de Linux para recibir actualizaciones oportunas

Para recibir una notificación cada vez que haya una actualización ascendente, suscríbase a la lista de anuncios de linux-kernel . Esto le permitirá recibir un correo electrónico cada vez que se lance un nuevo kernel para que pueda actualizarlo y enviarlo lo más rápido posible.