Qual è la differenza tra “select” vs “dipende” nel kernel di Linux Kconfig?

Quali sono le differenze nelle dipendenze tra selecte depends onnei file Kconfig dei kernel?

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.

Nell'esempio sopra, in che modo è FB_CIRRUSdiversamente correlato a FB && (ZORRO || PCI)quello che è FB_CFB_FILLRECT, FB_CFB_COPYAREAe FB_CFB_IMAGEBLIT?

Aggiornare

Ho notato che depend onnon fa molto in termini di ordine di compilazione.

Per esempio. Una build di successo di AppB dipende da un LibB collegato staticamente da costruire per primo. L'impostazione depends on LibBin Kconfig per AppB non forzerà la creazione del LibB per primo. L'impostazione select LibBsarà.

depends onindica che i simboli devono essere già selezionati =yin modo positivo ( ) per poter configurare questa opzione. Ad esempio, devono essere stati selezionati i depends on FB && (ZORRO || PCI)mezzi FBe (&&) o ZORROo (||) PCI. Per cose del genere make menuconfig, questo determina se verrà presentata o meno un'opzione.

selectimposta positivamente un simbolo. Ad esempio, select FB_CFB_FILLRECTsignificherà FB_CFB_FILLRECT=y. Ciò soddisfa una potenziale dipendenza di alcune altre opzioni di configurazione. Si noti che i documenti del kernel scoraggiano l'uso di questo per simboli "visibili" (che possono essere selezionati / deselezionati dall'utente) o per simboli che stessi hanno dipendenze, dal momento che questi non verranno controllati.

Riferimento: https://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt

depends significa che l'opzione appare nel menu solo se i suoi prerequisiti (il costrutto booleano dietro di essa) sono soddisfatti.

selectsignifica che, quando l'utente seleziona questa opzione, l'opzione fornita come argomento selectverrà automaticamente selezionata.

Mi piace pensare è come:

• selectè un "sottoinsieme" di depends, per quando esiste una sola dipendenza possibile per una funzione.

  Poiché esiste solo una possibile dipendenza, selectseleziona automaticamente tale opzione e ti risparmia il lavoro di scegliere esplicitamente la dipendenza prima manualmente.

  Questa automazione è ciò che si ottiene dalla restrizione del sottoinsieme di avere solo una possibile dipendenza.

• depends è più generale e funziona nei casi in cui una funzione dipende da un'interfaccia con più implementazioni.

  Ad esempio, su 4.15, ci sono 2 implementazioni BPF: classica ed estesa.

  Pertanto, la BPF_JITfunzionalità dipende da almeno una delle implementazioni abilitate:

  config BPF_JIT
      depends on HAVE_CBPF_JIT || HAVE_EBPF_JIT
  

  Dato che ci sono due possibili implementazioni per BFP_JIT, Kconfig non ha potuto selezionare sensibilmente quella giusta automaticamente.

  A volte vorrei poter dire: "se nessuna delle dipendenze viene soddisfatta, selezionala per impostazione predefinita", ciò consentirebbe di automatizzare ulteriormente le cose.

Ci sono anche effetti "qualcosa nasconde un'altra opzione su menuconfig", ma questi sono solo lanugine :-)