Como atualizar o kernel do Android para a versão mais recente do Linux estável

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

A parte que mais consome tempo é a apresentação inicial; uma vez que você está totalmente atualizado, não leva tempo algum para fazer o merge em uma nova versão, que geralmente contém não mais que 100 commits. Os benefícios que isso traz (mais estabilidade e melhor segurança para seus usuários) devem exigir este processo.

Como mesclar o kernel estável do Linux em um kernel Android

Primeiro você precisa descobrir qual versão do kernel seu dispositivo Android está executando.

Por mais trivial que pareça, é necessário saber por onde começar. Execute o seguinte comando na árvore do kernel:

fazer kernelversion

Ele retornará a versão em que você está. Os primeiros dois números serão usados ​​para descobrir o branch que você precisa (por exemplo, linux-4.4.y para qualquer kernel 4.4) e o último número será usado para determinar qual versão você precisa para começar a mesclar (por exemplo, se você estiver no 4.4 .21, você mesclará 4.4.22 em seguida).

Obtenha a última fonte do kernel em kernel.org

kernel.org abriga a última fonte do kernel em o repositório linux-stable . Na parte inferior da página, haverá três links de busca. Na minha experiência, o espelho do Google tende a ser o mais rápido, mas seus resultados podem variar. Execute os seguintes comandos:

git remote add linux-stable https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit fetch linux-stable

Decida se você deseja mesclar o kernel inteiro ou selecione os commits

Em seguida, você precisará escolher se deseja mesclar os commits ou selecioná-los. Aqui estão os prós e contras de cada um e quando você pode querer fazê-los.

NOTA: Se o código-fonte do seu kernel estiver na forma de um tarball, você provavelmente precisará selecioná-lo, caso contrário, obterá milhares de conflitos de arquivo porque o git está povoando o histórico baseado puramente no upstream, não no que o OEM ou CAF mudou. Basta pular para a etapa 4.

Apanhar cerejas:

Prós:

• Mais fácil de resolver conflitos, pois você sabe exatamente qual conflito está causando o problema.
• Mais fácil de rebase, pois cada commit é independente.
• Mais fácil de dividir se tiver problemas

Contras:

• Demora mais, pois cada commit deve ser escolhido individualmente.
• Um pouco mais difícil de dizer se o commit é do upstream à primeira vista

Ir

Prós :

• É mais rápido porque você não precisa esperar que todos os patches limpos sejam mesclados.
• É mais fácil ver quando um commit vem do upstream, pois você não será o commiter, mas o mantenedor do upstream será.

Contras:

• Resolver conflitos pode ser um pouco mais difícil, pois você precisará verificar qual commit está causando o conflito usando git log / git blame, ele não lhe dirá diretamente.
• Rebase é difícil, pois você não pode rebase uma mesclagem, ele oferecerá a escolha de todos os commits individualmente. No entanto, você não deve fazer rebasing com frequência, em vez disso, usar git revert e git merge onde possível.

Eu recomendaria fazer uma escolha seletiva para descobrir quaisquer conflitos de problema inicialmente, fazendo uma mesclagem, em seguida, reverter os commits do problema depois, para que a atualização seja mais fácil (já que a mesclagem é mais rápida depois de estar atualizado).

Adicione os commits à sua fonte, uma versão de cada vez

A parte mais importante deste processo é uma versão de cada vez. PODE haver um patch de problema em sua série de upstream, que pode causar um problema com a inicialização ou quebrar algo como som ou carregamento (explicado na seção de dicas e truques). Fazer alterações de versão incrementais é importante por este motivo, é mais fácil encontrar um problema em 50 commits do que mais de 2.000 commits para algumas versões. Eu só recomendaria fazer uma mesclagem completa depois de saber todos os commits de problemas e resoluções de conflitos.

Apanhar cerejas

Formato:

escolha a dedo ..

Exemplo:

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

Ir

Formato:

vá fundir

Exemplo:

git merge v3.10.74

Eu recomendo manter o controle dos conflitos em commits de mesclagem removendo os marcadores #.

Como resolver conflitos

Não podemos dar um guia passo a passo para resolver todos os conflitos, pois envolve um bom conhecimento da linguagem C, mas aqui estão algumas dicas.

Se você está mesclando, descubra qual commit está causando o conflito. Você pode fazer isso de duas maneiras:

1. git log -p v $ (make kernelversion) .. para obter as mudanças entre sua versão atual e a mais recente do upstream. O sinalizador -p fornecerá as mudanças feitas por cada commit para que você possa ver.
2. Execute git blame no arquivo para obter os hashes de cada commit na área. Você pode então executar git show –format = fuller para ver se o committer era de mainline / stable, Google ou CodeAurora.

• Descubra se você já tem o commit. Alguns fornecedores como Google ou CAF tentarão procurar bugs críticos no upstream, como a correção Dirty COW, e seus backports podem entrar em conflito com os upstream. Você pode executar git log –grep = ”” e ver se ele retorna algo. Se isso acontecer, você pode pular o commit (se escolher aleatoriamente usando git reset –hard && git cherry-pick –continue) ou ignorar os conflitos (remover o<<<<<>>>>>).
• Descubra se existe um backport que está atrapalhando a resolução. O Google e a CAF gostam de fazer backport de certos patches que estáveis, não. O Stable frequentemente precisará adaptar a resolução do comprometimento da linha principal à ausência de certos patches que o Google opta por backport. Você pode olhar o commit da linha principal executando git show (o hash da linha principal estará disponível na mensagem de confirmação do commit estável). Se houver um backport bagunçando tudo, você pode descartar as alterações ou usar a versão principal (que é o que você geralmente precisa fazer).
• Leia o que o commit está tentando fazer e veja se o problema já foi corrigido. Às vezes, o CAF pode corrigir um bug independente do upstream, o que significa que você pode substituir a correção do upstream ou descartá-la, como acima.

Caso contrário, pode ser apenas o resultado de uma adição CAF / Google / OEM, caso em que você só precisa embaralhar algumas coisas.

Aqui está um espelho do repositório kernel.org estável do linux no GitHub, que pode ser mais fácil para pesquisar listas de commits e diffs para resolução de conflitos. Eu recomendo ir primeiro para a lista de commits e localizar o commit problemático para ver o diff original para compará-lo com o seu.

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

Você também pode fazer isso por meio da linha de comando:

git log .. git show

Resolver resoluções tem tudo a ver com contexto. O que você SEMPRE deve fazer é certificar-se de que sua diferença final corresponda à do upstream executando os seguintes comandos em duas janelas separadas:

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

Habilitar reler

O Git tem um recurso chamado rerere (significa Reutilizar Resolução Gravada), o que significa que, quando detectar um conflito, ele registrará como você o resolveu para que possa reutilizá-lo posteriormente. Isso é especialmente útil para rebasers crônicos com mesclagem e seleção seletiva, pois você só precisa executar git add. && git –continue ao refazer a apresentação do upstream, pois o conflito será resolvido como você o resolveu anteriormente.

Ele pode ser habilitado executando o seguinte comando no repositório do kernel:

git config rerere.enabled true

Como fazer o git ao meio ao se deparar com um compilador ou erro de execução

Dado que você adicionará um número considerável de commits, é muito possível introduzir um compilador ou erro de tempo de execução. Em vez de apenas desistir, você pode usar a ferramenta bisect integrada do git para descobrir a causa raiz do problema! O ideal é que você construa e atualize cada versão do kernel à medida que adiciona, de forma que a divisão ao meio levará menos tempo se necessário, mas você pode dividir 5.000 commits sem problemas.

O que o git bisect fará é pegar uma gama de commits, de onde o problema está presente até onde não estava, e então começar a reduzir pela metade o intervalo de commit, permitindo que você construa e teste e deixe saber se é bom ou não . Isso continuará até que seja emitido o commit que está causando o seu problema. Nesse ponto, você pode corrigi-lo ou revertê-lo.

1. Começar ao meio: git bisect start
2. Rotule a revisão atual como ruim: git bisect bad
3. Rotule uma revisão como boa: git bisect good
4. Construir com a nova revisão
5. Com base no resultado (se o problema está presente ou não), diga git: git bisect good OU git bisect bad
6. Enxágüe e repita os passos 4-5 até que o problema seja encontrado!
7. Reverta ou corrija o commit do problema.

NOTA: As fusões precisarão executar temporariamente git rebase -i para aplicar todos os patches em seu branch para a bissetriz adequada, já que a bissetriz com as fusões no lugar frequentemente fará checkout nos commits upstream, o que significa que você não tem nenhum dos commits específicos do Android. Posso aprofundar isso mediante solicitação, mas acredite em mim, é necessário. Depois de identificar o commit do problema, você pode reverter ou rebase-o na fusão.

NÃO reprima as atualizações do upstream

Muitos novos desenvolvedores são tentados a fazer isso porque é “mais limpo” e “mais fácil” de gerenciar. Isso é terrível por alguns motivos:

• A autoria está perdida. É injusto para outros desenvolvedores ter seu crédito roubado por seu trabalho.
• A divisão em dois é impossível. Se você esmagar uma série de commits e algo for um problema nessa série, é impossível dizer qual commit causou um problema em uma squash.
• As escolhas futuras são mais difíceis. Se você precisa rebase com uma série comprimida, é difícil / impossível dizer de onde um conflito resulta.

Inscreva-se na lista de discussão do kernel do Linux para atualizações oportunas

Para ser notificado sempre que houver uma atualização upstream, inscreva-se no a lista linux-kernel-announce . Isso permitirá que você receba um e-mail sempre que um novo kernel for lançado, para que você possa atualizar e enviar o mais rápido possível.