Manter uma interface estável do módulo do kernel

É fundamental manter uma interface de módulo do kernel (KMI) estável para os módulos do fornecedor. O kernel da GKI é criado e enviado em formato binário, e os módulos de carregamento do fornecedor são criados em uma árvore separada. O kernel e os módulos do fornecedor do GKI resultantes precisam funcionar como se tivessem sido criados juntos.

Em geral, a comunidade do Linux não gosta da noção de estabilidade da ABI no kernel para o kernel principal. Diante de diferentes conjuntos de ferramentas, configurações e um kernel da linha principal do Linux em constante evolução, não é viável manter um KMI estável na linha principal. No entanto, é possível manter um KMI estável no ambiente de GKI com muitas restrições com estas restrições:

  • Apenas uma única configuração, gki_defconfig, pode ser usada para criar o kernel.

  • O KMI só é estável na mesma versão LTS e Android de um kernel, como android13-5.10, android12-5.10 ou android13-5.15.

    • Não há estabilidade do KMI para android-mainline.

  • Somente a cadeia de ferramentas Clang específica fornecida no AOSP e definida para a ramificação correspondente é usada para criar o kernel e os módulos.

  • Somente símbolos conhecidos que são usados por módulos, conforme especificado em uma lista de símbolos, são monitorados quanto à estabilidade e são considerados símbolos KMI.

    • O corolário é que os módulos do fornecedor precisam usar apenas símbolos KMI. Essa restrição é aplicada por falhas de carregamento de módulo se símbolos que não são do KMI forem necessários.

  • Depois que a ramificação da KMI é congelada, as mudanças são permitidas, mas não podem interromper a KMI. Essas mudanças incluem:

    • Mudanças na configuração
    • Mudanças no código do kernel
    • Mudanças na cadeia de ferramentas (incluindo atualizações)

Usar o processo de build hermético e o conjunto de ferramentas LLVM

O processo de build hermético garante um KMI estável com a descrição completa do ambiente de build em manifestos repo em kernel/manifest. Por exemplo, o manifesto para android13-5.15 inclui a cadeia de ferramentas, scripts de build e tudo o que é necessário para criar a imagem genérica do kernel (GKI). Os respectivos arquivos de configuração build.config, como a configuração de build do GKI build.config.gki.aarch64, garantem que as ferramentas incluídas sejam usadas corretamente para gerar resultados de build consistentes.

O uso de um processo de build hermético também garante que a descrição da ABI para a árvore seja consistente, seja gerada pelo Google (por exemplo, abi_gki_aarch64.xml para android13-5.15) ou em uma árvore local que inclua os módulos do fornecedor. As ferramentas para criar e comparar a descrição da ABI para a Interface de Módulo do Kernel (KMI, na sigla em inglês) também são fornecidas como parte do repositório descrito pelo manifesto.

O conjunto de ferramentas usado para criar o kernel de GKI precisa ser totalmente compatível com o conjunto usado para criar módulos do fornecedor. A partir do Android 10, todos os kernels do Android precisam ser criados com uma cadeia de ferramentas LLVM. Com o GKI, o conjunto de ferramentas LLVM usado para criar kernels de produtos e módulos de fornecedores precisa gerar a mesma ABI que o conjunto de ferramentas LLVM do AOSP, e os parceiros precisam garantir que o KMI seja compatível com o kernel do GKI. É altamente recomendável usar as ferramentas de build fornecidas, porque elas oferecem a melhor compatibilidade.

Qual é a próxima etapa?