Visão geral dos módulos do kernel

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

Módulos GKI

Os módulos Generic Kernel Image (GKI) são usados ​​para fornecer funcionalidade de kernel não necessária para inicialização separada do kernel de núcleo genérico. Com os módulos GKI, você pode escolher a funcionalidade específica do kernel a ser usada, geralmente reduzindo o tamanho da imagem do kernel e o consumo de memória de tempo de execução. A redução no tamanho torna o GKI adequado para dispositivos Android Go e outros fatores de forma com recursos restritos.

Os módulos GKI também fornecem 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 a criação de 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 de tempo de compilação do kernel para diferenciar entre GKI e outros módulos em tempo de execução. Os módulos não assinados têm permissão para carregar, desde que usem apenas símbolos que aparecem na lista de permissões ou fornecidos por outros módulos não assinados.

Existem dois tipos lógicos de módulos GKI: módulo GKI protegido e módulo GKI desprotegido .

Módulo GKI protegido

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

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

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

Módulo GKI desprotegido

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

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

Módulos do fornecedor

Um módulo de fornecedor é entregue por parceiros para implementar o SoC e a funcionalidade específica do dispositivo. Qualquer módulo de kernel existente que não seja fornecido como parte do kernel GKI pode ser fornecido como um módulo de fornecedor.

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

Se um driver ou estrutura de kernel existir no ACK, mas não for fornecido como parte do kernel GKI, os fornecedores poderão modificar o driver e entregá-lo como um módulo de fornecedor. Essas modificações são desencorajadas para módulos não específicos do fornecedor porque a mesma funcionalidade pode ser fornecida com o kernel GKI em uma versão futura. Quando o kernel GKI contiver funcionalidade fornecida por um módulo de fornecedor, o módulo de fornecedor não será carregado. Por exemplo, CONFIG_GREYBUS não está definido para GKI no Android 11, portanto, os fornecedores podem fornecer módulos de fornecedores greybus. No entanto, CONFIG_GREYBUS pode ser ativado como um GKI integrado ou módulo no Android 12, caso em que os módulos do fornecedor 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 fornecidos como módulos do fornecedor.

Você pode entregar módulos de fornecedor na imagem vendor ou vendor_boot . Os módulos necessários no início do processo de inicialização devem estar em vendor_boot . Há um custo de tempo de inicialização associado ao carregamento de módulos de vendor_boot .