Visão geral dos módulos do kernel

Há dois tipos de módulos do kernel: módulos GKI independentes de hardware e módulos do fornecedor específicos de hardware. Esta página fornece uma visão geral dos dois tipos de módulos.

Módulos GKI

Os módulos de imagem genérica do kernel (GKI, na sigla em inglês) são usados para fornecer recursos do kernel que não são necessários para inicialização separados do kernel genérico principal. Com os módulos GKI, é possível escolher recursos específicos do kernel para usar, geralmente reduzindo o tamanho da imagem do kernel e o consumo de memória de execução. A redução no tamanho torna a GKI adequada para dispositivos Android Go e outros formatos com recursos restritos.

Os módulos do GKI também oferecem um mecanismo para permitir que os fornecedores incorporem novos recursos upstream após o marco de congelamento do KMI. O código integrado não pode ser substituído sem criar outra imagem, enquanto o código entregue como um módulo pode ser substituído por outro módulo.

Os módulos GKI usam a infraestrutura de assinatura do tempo de build do kernel para diferenciar a GKI de outros módulos no ambiente de execução. Módulos não assinados podem ser carregados desde que usem apenas símbolos que aparecem na lista de permissões ou fornecidos por outros módulos não assinados.

Há dois tipos lógicos de módulos GKI: módulo GKI protegido e módulo GKI não protegido.

Módulo GKI protegido

Um módulo GKI protegido é fornecido pelo Google, não é restrito de forma alguma e se comporta como se fosse criado com o kernel após o carregamento. Além disso, os módulos GKI protegidos têm as características abaixo:

  • Módulos GKI protegidos têm acesso a símbolos de kernel que não são do KMI e que não estão disponíveis para módulos de fornecedores ou módulos GKI desprotegidos.
  • Os módulos de GKI protegidos podem exportar símbolos que se tornam parte da plataforma KMI, desde que esses símbolos sejam citados em uma lista de símbolos.
  • Os módulos de GKI protegidos não podem ser substituídos pelos módulos do fornecedor.

Um módulo GKI protegido é a classe padrão de módulos GKI. Todos os módulos GKI são considerados protegidos no momento do congelamento do KMI.

Módulo GKI não protegido

Um módulo GKI desprotegido pode ser substituído por um módulo do fornecedor. Após o congelamento do KMI, um módulo GKI protegido pode ser reclassificado como desprotegido se a equipe do GKI decidir que os fornecedores precisam substituir a implementação padrão por uma versão que inclui novos recursos do Linux upstream. Na próxima versão do GKI, os módulos não protegidos são reclassificados como protegidos depois que o código upstream é lançado em um kernel comum do Android (ACK). Os módulos GKI não protegidos têm as seguintes características:

  • Os módulos GKI não protegidos têm o mesmo acesso aos símbolos exportados que os módulos do fornecedor.
  • Módulos GKI não protegidos não podem exportar símbolos exportados por módulos GKI protegidos.
  • Os módulos GKI não protegidos precisam preservar todas as interfaces KMI como parte do kernel principal.
  • Os módulos GKI não protegidos podem ser substituídos pelos módulos do fornecedor.

Módulos do fornecedor

Um módulo de fornecedor é fornecido pelos parceiros para implementar o SoC e os recursos específicos do dispositivo. Qualquer módulo do kernel atual que não seja entregue como parte do kernel de GKI pode ser entregue como um módulo de fornecedor.

Como uma das principais metas do projeto GKI é minimizar o código específico do hardware no kernel principal, os fornecedores podem esperar que o kernel do GKI não inclua módulos que gerenciam claramente o próprio hardware. Por exemplo, o fornecedor ABC Inc. pode esperar que configurações como CONFIG_ABC_SOC_SUPPORT não sejam ativadas como módulos GKI integrados ou carregáveis sem o suporte deles.

Se um driver ou framework do kernel existir no ACK, mas não for entregue como parte do kernel da GKI, os fornecedores poderão modificar o driver e entregá-lo como um módulo do fornecedor. Essas modificações não são recomendadas para módulos que não são específicos do fornecedor, porque os mesmos recursos podem ser fornecidos com o kernel do GKI em uma versão futura. Quando o kernel de GKI contém recursos fornecidos por um módulo de fornecedor, o módulo do fornecedor não é carregado. Por exemplo, CONFIG_GREYBUS não está definido para GKI no Android 11, então os fornecedores podem fornecer módulos de barra cinza. No entanto, CONFIG_GREYBUS pode ser ativado como um módulo ou GKI integrado no Android 12. Nesse caso, os módulos do fornecedor do Greybus não serão carregados. Uma prática recomendada é usar a versão upstream de drivers não específicos do fornecedor, se eles forem entregues como módulos do fornecedor.

É possível enviar módulos de fornecedores na imagem vendor ou vendor_boot. Os módulos necessários no início do processo de inicialização precisam estar em vendor_boot. Há um custo de inicialização associado ao carregamento de módulos do vendor_boot.