Cómo migrar kernel de Linux a una versión de núcleo superior

Estoy trabajando en algunos modules de kernel de Linux y mi kernel actual es 3.8 , quiero actualizarlo a kernel 3.10 .

Pensé en dos maneras de hacerlo:

  1. O mira una twig 3.10 separado y luego combínalo con mi twig 3.8 actual.
  2. O parche 3.8 con parche 3.9 y luego parchealo con parche 3.10 (parches disponibles en kernel.org son una diferencia de la versión actual y la anterior, lo que creo)

¿Qué enfoque debo seguir? Hay una mejor manera de hacerlo?

Estoy usando git como el software de control de versiones.

Bueno, en términos de git puedes elegir de cualquier forma.

Puede tomar las fonts de v3.8, crear una twig separada (llamada, digamos, my_modules), aplicar los cambios en esa twig, confirmarlos. Luego debe fusionar esa twig con las fonts reales del kernel (yo sugeriría con el master upstream pero puede elegir cualquier otro punto (commit) en el historial de desarrollo del kernel): git merge <chosen-branch-o-tag-o-commit> . En este punto, puede que tenga que resolver los conflictos de fusión, si hay alguno, actualice su module a la nueva API interna del kernel, etc. y luego confirme el estado fusionado. Ver git merge --help y otra documentation relevante de git. Ahora tiene sus cambios adaptados a la versión elegida de kernel y puede ver la diferencia entre kernel cadena arriba y parcheado: git diff <chosen-branch-o-tag-o-commit> HEAD . La image de confirmación resultante se vería así:

 A - ... - B \ \ D1 - D2... - M 

donde A es el punto de bifurcación inicial (kernel 3.8), B es la confirmación con la que se fusionó (un kernel más nuevo), D1..DN son las confirmaciones de su controller y M es la fusión.

Alternativamente, también puede usar otro enfoque llamado rebase. En este caso, "trasplanta" la secuencia de confirmaciones iniciales a la nueva raíz elegida: git rebase -i B Entonces git intentará volver a aplicar la secuencia completa D1 … DN a la nueva raíz B iterativamente. Tenga en count que en cada paso 1 … N puede get un conflicto que necesita resolver y luego continuar el process de rebase con git rebase --continue rebase git rebase --continue . En el extremo [exitoso] obtendrás una nueva secuencia de compromiso D'1 – D'N creciendo desde B:

 A - ... - B \ D'1 - .... D'N 

Tenga en count que técnicamente D'1 … D'N mientras mira / similar / a su D1 original … DN son diferentes. Tienen su propio time de compromiso, pueden tener text de parche ligeramente diferente, etc. Dependiendo de sus necesidades, pueden o no ser lo que necesita.

    Intereting Posts