Qual é a diferença entre “select” vs “depends” no kernel do Kconfig do Linux?

Question

Quais são as diferenças nas dependências entre select e depends on nos arquivos Kconfig dos kernels?

config FB_CIRRUS
tristate "Cirrus Logic support"
depends on FB && (ZORRO || PCI)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
---help---
This enables support for Cirrus Logic GD542x/543x based boards on
Amiga: SD64, Piccolo, Picasso II/II+, Picasso IV, or EGS Spectrum.

No exemplo acima, como FB_CIRRUS é difensamente relacionado a FB && (ZORRO || PCI) do que a FB_CFB_FILLRECT , FB_CFB_COPYAREA e FB_CFB_IMAGEBLIT ?

Atualizar

Eu notei que depend on não faz muito em termos de ordem de compilação.

Por exemplo. Uma compilação bem-sucedida do AppB depende de uma LibB vinculada estaticamente a ser construída primeiro. Definir depends on LibB no Kconfig para o AppB não forçará a LibB a ser construída primeiro. Definindo select LibB será.

    

Answer 1

depends on indica que os símbolos já devem estar selecionados positivamente ( =y ) para que essa opção seja configurada. Por exemplo, depends on FB && (ZORRO || PCI) significa FB deve ter sido selecionado e (& &) ZORRO ou (||) PCI . Para coisas como make menuconfig , isso determina se uma opção será ou não apresentada.

select define positivamente um símbolo. Por exemplo, select FB_CFB_FILLRECT significa FB_CFB_FILLRECT=y . Isso preenche uma dependência potencial de algumas outras opções de configuração. Note que os documentos do kernel desencorajam o uso disso para símbolos "visíveis" (que podem ser selecionados / desmarcados pelo usuário) ou para símbolos que possuem dependências, já que aqueles não serão verificados.

Referência: link

    

Answer 2

depends significa que a opção só aparece no menu se seus pré-requisitos (a construção booleana subjacente) forem atendidos.

select significa que, quando o usuário seleciona essa opção, a opção fornecida como argumento para select será selecionada automaticamente.

    

Answer 3

Eu gosto de pensar em como:

• select é um "subconjunto" de depends , para quando há apenas uma dependência possível para um recurso.

  Como existe apenas uma dependência possível, select apenas seleciona essa opção automaticamente e economiza o trabalho de escolher explicitamente a dependência manualmente primeiro.

  Essa automação é o que você ganha com a restrição de subconjuntos de ter apenas uma possível dependência.

• depends é mais geral e funciona em casos em que um recurso depende de uma interface que possui várias implementações.

  Por exemplo, no 4.15, existem duas implementações de BPF: Clássica e Estendida.

  Portanto, o recurso BPF_JIT depende da ativação de pelo menos uma das implementações:

  config BPF_JIT
      depends on HAVE_CBPF_JIT || HAVE_EBPF_JIT
  

  Como existem duas implementações possíveis para BFP_JIT , o Kconfig não conseguiu selecionar o caminho certo automaticamente.

  Por vezes, gostaria de poder dizer: "se nenhuma das dependências for cumprida, selecione esta por predefinição", o que permitiria automatizar ainda mais as coisas.

Há também "algo esconde outra opção no menuconfig" efeitos, mas estes são apenas fluff :-)