Qual é a diferença entre "select" e "depende" no kconfig do kernel Linux?

Quais são as diferenças nas dependências entre selecte depends onnos 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_CIRRUSdiffrently relacionadas com FB && (ZORRO || PCI)que é para FB_CFB_FILLRECT, FB_CFB_COPYAREAe FB_CFB_IMAGEBLIT?

Atualizar

Percebi que depend onisso realmente 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 compilada primeiro. A configuração depends on LibBno Kconfig para AppB não forçará o LibB a ser construído primeiro. Definir select LibBvontade.

depends onindica que os símbolos já devem estar selecionados positivamente ( =y) para que esta opção seja configurada. Por exemplo, os depends on FB && (ZORRO || PCI)meios FBdevem ter sido selecionados e (&&) ZORROou (||) PCI. Para coisas como make menuconfigisso, determina se uma opção será ou não apresentada.

selectdefine positivamente um símbolo. Por exemplo, select FB_CFB_FILLRECTisso significa FB_CFB_FILLRECT=y. Isso preenche uma dependência potencial de outras opções de configuração. Observe 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, pois eles não serão verificados.

Referência: https://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt

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

selectsignifica que, quando o usuário selecionar essa opção, a opção fornecida como argumento selectserá automaticamente selecionada.

Eu gosto de pensar é como:

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

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

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

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

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

  Portanto, o BPF_JITrecurso depende de pelo menos uma das implementações estar ativada:

  config BPF_JIT
      depends on HAVE_CBPF_JIT || HAVE_EBPF_JIT
  

  Como existem duas implementações possíveis BFP_JIT, o Kconfig não pôde selecionar automaticamente a correta corretamente.

  Às vezes eu gostaria de poder dizer: "se nenhuma das dependências for atendida, selecione essa por padrão", isso permitiria automatizar ainda mais as coisas.

Também existem efeitos "algo oculta outra opção no menuconfig", mas estes são apenas leves :-)