Jaka jest różnica między „select” a „zależy” w jądrze Linuksa Kconfig?

Jakie są różnice w zależnościach między plikami Kconfig selecti pomiędzy depends onnimi?

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.

W powyższym przykładzie, w jaki sposób FB_CIRRUSróżni się to FB && (ZORRO || PCI)niż jest FB_CFB_FILLRECT, FB_CFB_COPYAREAi FB_CFB_IMAGEBLIT?

Aktualizacja

Zauważyłem, że depend ontak naprawdę niewiele robi w zakresie kolejności kompilacji.

Na przykład. Pomyślna kompilacja AppB zależy od statycznie połączonego LibB, który ma zostać zbudowany jako pierwszy. Ustawienie depends on LibBw Kconfig dla AppB nie wymusi zbudowania LibB jako pierwszego. Ustawienie select LibBbędzie.

depends onwskazuje, że symbol (y) musi być już pozytywnie wybrany ( =y), aby można było skonfigurować tę opcję. Na przykład depends on FB && (ZORRO || PCI)środki FBmusiały zostać wybrane, a (&&) albo ZORROalbo (||) PCI. W przypadku takich rzeczy make menuconfigokreśla to, czy opcja będzie prezentowana.

selectpozytywnie ustawia symbol. Na przykład select FB_CFB_FILLRECTbędzie oznaczać FB_CFB_FILLRECT=y. Spełnia to potencjalną zależność niektórych innych opcji konfiguracji. Zauważ, że dokumenty jądra odradzają stosowanie tego w przypadku „widocznych” symboli (które użytkownik może wybrać / odznaczyć) lub symboli, które same mają zależności, ponieważ nie zostaną one sprawdzone.

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

depends oznacza, że ​​opcja pojawia się w menu tylko wtedy, gdy spełnione są jej wymagania wstępne (konstrukcja boolowska za nią).

selectoznacza, że ​​gdy użytkownik wybierze tę opcję, opcja podana jako argument selectzostanie automatycznie wybrana.

Lubię myśleć o:

• selectjest „podzbiorem” depends, ponieważ gdy istnieje tylko jedna możliwa zależność dla funkcji.

  Ponieważ istnieje tylko jedna możliwa zależność, selectpo prostu wybiera tę opcję automatycznie i oszczędza ci pracy polegającej na jawnym ręcznym wybieraniu zależności najpierw.

  Tę automatyzację uzyskuje się dzięki ograniczeniu podzestawu posiadania tylko jednej możliwej zależności.

• depends jest bardziej ogólny i działa w przypadkach, gdy funkcja zależy od interfejsu, który ma wiele implementacji.

  Na przykład w 4.15 są 2 implementacje BPF: Classic i Extended.

  Dlatego BPF_JITfunkcja zależy od włączenia co najmniej jednej implementacji:

  config BPF_JIT
      depends on HAVE_CBPF_JIT || HAVE_EBPF_JIT
  

  Ponieważ istnieją dwie możliwe implementacje BFP_JIT, Kconfig nie mógł rozsądnie automatycznie wybrać właściwej.

  Czasami chciałbym powiedzieć: „jeśli żadna z zależności nie jest spełniona, wybierz tę domyślnie”, co pozwoli na dalszą automatyzację rzeczy.

Są też „coś ukrywa inną opcję w menuconfig”, ale to tylko puch :-)