Comment mettre à jour votre noyau Android vers la dernière version stable de Linux

Nous avons couvert des guides sur les noyaux Android, tels que «Comment construire un noyau personnalisé» et «Meilleurs noyaux personnalisés pour Android», mais aujourd'hui, nous allons vous montrer comment améliorer votre noyau avec la dernière version de Linux.

Sachez que ceci est avancé . Si vous n'avez jamais compilé de noyau, vous devriez suivre le guide "Comment construire un noyau personnalisé" (lien ci-dessus), et ce guide impliquera la sélection et la fusion des commits à partir de la dernière version de Linux - noyau stable avec votre noyau Android avant de le compiler.

La mise à niveau de votre noyau Android vers la dernière version de Linux présente de nombreux avantages, tels que la mise à jour des dernières mises à jour de sécurité et corrections de bugs - nous expliquerons ci-après certains avantages et inconvénients de ce guide.

Qu'est-ce que le noyau Linux-Stable?

Comme son nom l’indique, Linux-stable est le bras stable du noyau Linux. L’autre branche est appelée «ligne principale», qui est la branche principale . Tout le développement du noyau Linux a lieu dans la ligne principale et suit généralement ce processus:

  1. Linus Torvalds prendra une série de correctifs de ses responsables pendant deux semaines.
  2. Après ces deux semaines, il publie un noyau rc1 (par exemple 4.14-rc1).
  3. Pour chaque semaine pendant les 6 à 8 prochaines semaines, il publiera un autre noyau RC (par exemple, 4.14-rc2, 4.14-rc3, etc.), qui ne contient que des correctifs de bogues et de régression.
  4. Une fois jugé stable, il sera publié sous forme d'archive à télécharger sur organisation (par exemple, 4.14).

Que sont les noyaux LTS?

Chaque année, Greg choisit un noyau et le maintient pendant deux ans (LTS) ou six ans (LTS étendu). Ceux-ci sont conçus pour avoir des produits qui ont besoin de stabilité (comme les téléphones Android ou autres appareils IOT). Le processus est exactement le même que ci-dessus, il ne se produit que plus longtemps. Il existe actuellement six noyaux LTS (qui peuvent toujours être consultés sur la page des versions de kernel.org):

  • 4.14 (LTS), maintenu par Greg Kroah-Hartman
  • 4.9 (LTS), maintenu par Greg Kroah-Hartman
  • 4.4 (eLTS), maintenu par Greg Kroah-Hartman
  • 4.1 (LTS), maintenu par Sasha Levin
  • 3.16 (LTS), maintenu par Ben Hutchings
  • 3.2 (LTS), maintenu par Ben Hutchings

Quels sont les avantages de la mise en amont de mon noyau Android sous Linux Stable?

Lorsque des vulnérabilités importantes sont divulguées / corrigées, les noyaux stables sont les premiers à les obtenir. Ainsi, votre noyau Android sera beaucoup plus sûr contre les attaques, les failles de sécurité et les bogues en général.

La version stable de Linux inclut des correctifs pour de nombreux pilotes que mon périphérique Android n'utilise pas. N'est-ce pas inutile?

Oui et non, selon la définition que vous donnez à «la plupart du temps». Le noyau Linux peut inclure beaucoup de code qui reste inutilisé sur le système Android, mais cela ne garantit pas qu'il n'y aura pas de conflits de ces fichiers lors de la fusion de nouvelles versions! Comprenez que pratiquement personne ne construit chaque partie du noyau, pas même les distributions Linux les plus courantes comme Ubuntu ou Mint. Cela ne signifie pas que vous ne devriez pas prendre ces correctifs car il existe des correctifs pour les pilotes que vous exécutez. Prenez par exemple arm / arm64 et ext4, qui sont respectivement l’architecture Android et le système de fichiers les plus courants. Dans 4.4, de 4.4.78 (version de la dernière balise Oreo CAF) à 4.4.121 (dernière balise amont), ce sont les numéros suivants pour les validations de ces systèmes:

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

La partie qui demande le plus de temps est l’introduction initiale; une fois que vous êtes à jour, il ne faut pas beaucoup de temps pour fusionner une nouvelle version, qui ne contient généralement pas plus de 100 commits. Les avantages que cela apporte (plus de stabilité et une sécurité accrue pour vos utilisateurs) devraient toutefois nécessiter ce processus.

Comment fusionner un noyau stable Linux dans un noyau Android

Vous devez d’abord déterminer la version du noyau de votre appareil Android.

Aussi trivial que cela puisse paraître, il est nécessaire de savoir par où commencer. Exécutez la commande suivante dans votre arborescence du noyau:

 faire kernelversion 

Il retournera la version que vous utilisez. Les deux premiers nombres seront utilisés pour déterminer la branche dont vous avez besoin (par exemple, linux-4.4.y pour tout noyau 4.4) et le dernier numéro sera utilisé pour déterminer la version à fusionner (par exemple, si vous utilisez la version 4.4). .21, vous allez fusionner 4.4.22 ensuite).

Récupérez le dernier code source de kernel.org

kernel.org héberge la dernière source de noyau dans le référentiel Linux-stable. Au bas de cette page, il y aura trois liens de récupération. D'après mon expérience, le miroir de Google a tendance à être le plus rapide, mais vos résultats peuvent varier. Exécutez les commandes suivantes:

 git remote ajoute linux-stable //kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit va chercher linux-stable 

Décidez si vous voulez fusionner le noyau entier ou sélectionner les commits

Ensuite, vous devrez choisir si vous souhaitez fusionner les commits ou les sélections. Voici le pour et le contre de chacun et à quel moment vous voudrez peut-être les faire.

REMARQUE: Si le code source de votre noyau est sous la forme d'une archive, vous aurez probablement besoin de sélectionner, sinon vous obtiendrez des milliers de conflits de fichiers car git remplit l'historique uniquement en amont, et non ce que le fabricant OEM ou le CAF a modifié. Passez directement à l'étape 4.

Cueillette des cerises:

Avantages:

  • Plus facile de résoudre les conflits car vous savez exactement quel conflit est à l'origine du problème.
  • Plus facile à rebaser car chaque commit est seul.
  • Plus facile à diviser en deux si vous rencontrez des problèmes

Les inconvénients:

  • Cela prend plus de temps car chaque commit doit être sélectionné individuellement.
  • Un peu plus difficile de dire si le commit est de l'amont à première vue

Fusionner

Avantages :

  • C'est plus rapide car vous n'avez pas à attendre la fusion de tous les correctifs clairs.
  • Il est plus facile de voir quand un commit est en amont car vous ne serez pas l'auteur, mais le responsable en amont le sera.

Les inconvénients:

  • La résolution des conflits peut s'avérer un peu plus difficile, car vous devrez rechercher le commit à l'origine du conflit à l'aide de git log / git blame. Cela ne vous le dira pas directement.
  • Il est difficile de changer de base car vous ne pouvez pas annuler une fusion, il vous proposera de sélectionner tous les commits individuellement. Cependant, vous ne devriez pas rebasonner souvent, mais utilisez plutôt git revert et git fusion si possible.

Je vous recommanderais de choisir soigneusement les conflits de problèmes, de faire une fusion, puis de rétablir le problème par la suite, afin de faciliter la mise à jour (car la fusion est plus rapide après la mise à jour).

Ajoutez les commits à votre source, une version à la fois

La partie la plus importante de ce processus est la version une à la fois. Il PEUT y avoir un correctif dans votre série en amont, qui pourrait causer un problème de démarrage ou casser quelque chose comme un son ou une charge (expliqué dans la section conseils et astuces). Faire des changements de version incrémentiels est important pour cette raison, il est plus facile de trouver un problème dans 50 commits que plus de 2 000 commits pour certaines versions. Je ne recommanderais de faire une fusion complète que si vous connaissez tous les problèmes et les résolutions de conflits.

Cueillette des cerises

Format:

 git cherry-pick .. 

Exemple:

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

Fusionner

Format:

 fusionner 

Exemple:

fusion de git v3.10.74

Je recommande de garder une trace des conflits dans les commits de fusion en supprimant les marqueurs #.

Comment résoudre les conflits

Nous ne pouvons pas vous donner de guide pas à pas pour la résolution de chaque conflit car il implique une bonne connaissance du langage C, mais voici quelques astuces.

Si vous fusionnez, déterminez quel commit est à l'origine du conflit. Vous pouvez le faire de deux façons:

  1. git log -pv $ (make kernelversion) .. pour obtenir les changements entre votre version actuelle et la plus récente en amont. L'option -p vous indiquera les modifications apportées par chaque commit afin que vous puissiez voir.
  2. Exécutez git blame sur le fichier pour obtenir les hachages de chaque commit dans la zone. Vous pouvez ensuite exécuter git show –format = fuller pour voir si le committer était de mainline / stable, Google ou CodeAurora.
  • Déterminez si vous avez déjà le commit. Certains fournisseurs tels que Google ou CAF tenteront de rechercher des bogues critiques en amont, tels que le correctif COW sale, et leurs backports pourraient entrer en conflit avec ceux en amont. Vous pouvez exécuter git log –grep = ”” et voir s'il renvoie quoi que ce soit. Si tel est le cas, vous pouvez ignorer la validation (si la sélection est effectuée à l'aide de git reset –hard && git cherry-pick –continue) ou ignorer les conflits (supprimez le <<<<< >>>>>).
  • Déterminez s'il y a eu un backport perturbant la résolution. Google et la CAF aiment reloger certains correctifs stables. Stable devra souvent adapter la résolution de la ligne principale à l’absence de certains correctifs que Google choisit d’archiver. Vous pouvez regarder la validation de la ligne principale en exécutant git show (le hachage de la ligne principale sera disponible dans le message de validation de la validation stable). Si un port arrière gâche le problème, vous pouvez soit ignorer les modifications, soit utiliser la version principale (ce que vous devez généralement faire).
  • Lisez ce que le commit essaie de faire et voyez si le problème est déjà résolu. Parfois, CAF corrige un bogue indépendant de l’amont, ce qui signifie que vous pouvez écraser son correctif pour l’amont ou le supprimer, comme ci-dessus.

Sinon, cela pourrait simplement être le résultat d'une addition CAF / Google / OEM, auquel cas il vous suffirait de mélanger certaines choses.

Voici un miroir du référentiel linux-stable kernel.org sur GitHub, qui peut être plus facile pour rechercher des listes de validation et des diffs pour la résolution de conflits. Je vous recommande d’aller d’abord dans la vue des listes de validation, puis de localiser le problème pour consulter le diff original et de le comparer au vôtre.

Exemple d'URL: //github.com/nathanchance/linux-stable/commits/linux-3.10.y/arch/arm64/mm/mmu.c

Vous pouvez également le faire via la ligne de commande:

 Git Log .. Git Show 

Résoudre des résolutions est une question de contexte. Ce que vous devez TOUJOURS faire est de vous assurer que votre diff final correspond à celui en amont en exécutant les commandes suivantes dans deux fenêtres distinctes:

 git diff HEAD git diff v $ (make kernelversion) .. $ (balise git --sort = -taggerdate -lv $ (make kernelversion | cut -d. -f 1, 2) * | head -n1) 

Activer le rerere

Git a une fonctionnalité appelée rerere (signifie Réutiliser la résolution enregistrée), ce qui signifie que lorsqu'il détecte un conflit, il enregistre la façon dont vous l'avez résolu afin que vous puissiez le réutiliser ultérieurement. Ceci est particulièrement utile pour les rebaseurs chroniques qui fusionnent et qui choisissent les cerises, car vous aurez juste besoin de lancer git add. && git –continue lors de la restauration de la collecte en amont, car le conflit sera résolu de la manière dont vous l'avez résolu auparavant.

Il peut être activé en exécutant la commande suivante dans votre référentiel de noyau:

 git config rerere.enabled true 

Comment créer une bissect lorsque vous rencontrez un compilateur ou une erreur d'exécution

Étant donné que vous allez ajouter un nombre considérable de commits, il est très possible que vous introduisiez une erreur de compilation ou une erreur d’exécution. Au lieu d'abandonner, vous pouvez utiliser l'outil de bissect intégré de git pour déterminer la cause première du problème! Idéalement, vous allez créer et mettre à jour chaque version du noyau au fur et à mesure que vous l'ajoutez. Ainsi, la bissectisation prendra moins de temps si nécessaire, mais vous pouvez diviser 5 000 commits sans problème.

Ce que git bisect va faire, c'est prendre une série de commits, de l'endroit où le problème est présent à l'endroit où il ne l'était pas, puis commencer à réduire de moitié la plage de validation, ce qui vous permet de construire et de tester et de lui indiquer si elle est bonne ou non. . Cela continuera jusqu'à ce que le commit cause votre problème. À ce stade, vous pouvez résoudre le problème ou le rétablir.

  1. Commencer la bissection: git bisect start
  2. Étiquetez la révision actuelle en tant que mauvaise: git bisect bad
  3. Étiquetez une révision comme bonne: biss git bien
  4. Construire avec la nouvelle révision
  5. Sur la base du résultat (si le problème est présent ou non), dites à git: bissect git bon OU bissect git mauvais
  6. Rincez et répétez les étapes 4 et 5 jusqu'à ce que le problème soit résolu!
  7. Rétablir ou corriger le commit du problème.

REMARQUE: Les fusions devront exécuter temporairement git rebase -i pour appliquer tous les correctifs à votre branche afin de les bissecter correctement, car la bissectivité avec les fusions en place entraîne souvent des extractions sur les validations en amont, ce qui signifie que vous n'avez aucune des validations spécifiques à Android. Je peux aller plus en profondeur sur cette demande, mais croyez-moi, c'est nécessaire. Une fois que vous avez identifié le problème de validation, vous pouvez l'inverser ou le re-baser dans la fusion.

Ne pas écraser les mises à jour en amont

Beaucoup de nouveaux développeurs sont tentés de le faire car c'est «plus propre» et «plus facile» à gérer. C'est terrible pour plusieurs raisons:

  • La paternité est perdue. Il est injuste pour les autres développeurs de voir leur travail compromis.
  • Bisecter est impossible. Si vous écrasez une série de commits et que quelque chose est un problème de cette série, il est impossible de dire quel commettre a causé un problème dans un squash.
  • Les futurs choix de cerises sont plus difficiles. Si vous devez redéfinir le jeu avec une série réduite, il est difficile / impossible de dire d'où provient un conflit.

Abonnez-vous à la liste de diffusion du noyau Linux pour des mises à jour rapides

Pour être averti chaque fois qu'il y a une mise à jour en amont, abonnez-vous à la liste linux-kernel-advert. Cela vous permettra d’avoir un email chaque fois qu’un nouveau noyau sera publié afin que vous puissiez mettre à jour et pousser le plus rapidement possible.

Des Articles Intéressants