В чем разница между «выбрать» и «зависит» в ядре Linux Kconfig?

Каковы различия в зависимости между selectи depends onв файлах ядра Kconfig?

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.

В приведенном выше примере, как по- FB_CIRRUSразному связано с FB && (ZORRO || PCI)чем FB_CFB_FILLRECT, FB_CFB_COPYAREAи FB_CFB_IMAGEBLIT?

Обновить

Я заметил, что на depend onсамом деле не очень много с точки зрения порядка компиляции.

Например. Успешная сборка AppB зависит от статически связанной LibB, которая будет собрана первой. Установка depends on LibBв Kconfig для AppB не заставит LibB собираться первым. Постановка select LibBбудет.

depends onуказывает, что символ (ы) уже должен быть положительно выбран ( =y) для настройки этой опции. Например, должны быть выбраны depends on FB && (ZORRO || PCI)средние значения FBи (&&) либо ZORRO(||) PCI. Для таких вещей, как make menuconfig, это определяет, будет ли опция представлена.

selectположительно устанавливает символ. Например, select FB_CFB_FILLRECTбудет значить FB_CFB_FILLRECT=y. Это удовлетворяет потенциальной зависимости некоторых других опций конфигурации. Обратите внимание, что документы ядра не рекомендуют использовать это для «видимых» символов (которые могут быть выбраны / отменены пользователем) или для символов, которые сами имеют зависимости, так как они не будут проверены.

Ссылка: https://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt

depends означает, что опция отображается в меню, только если выполнены ее предварительные условия (логическая конструкция за ней).

selectозначает, что когда пользователь выбирает эту опцию, опция, заданная в качестве аргумента для, selectбудет выбрана автоматически.

Мне нравится думать о том, как:

• selectявляется «подмножеством» depends, когда существует только одна возможная зависимость для функции.

  Поскольку существует только одна возможная зависимость, selectпросто выбирайте эту опцию автоматически, и это избавляет вас от необходимости явного выбора зависимости вручную.

  Эта автоматизация - это то, что вы получаете от ограничения подмножества наличия только одной возможной зависимости.

• depends является более общим и работает в тех случаях, когда функция зависит от интерфейса, имеющего несколько реализаций.

  Например, в 4.15 есть 2 реализации BPF: Классическая и Расширенная.

  Следовательно, BPF_JITфункция зависит как минимум от одной из включенных реализаций:

  config BPF_JIT
      depends on HAVE_CBPF_JIT || HAVE_EBPF_JIT
  

  Поскольку существует две возможные реализации BFP_JIT, Kconfig не смог разумно выбрать правильный вариант автоматически.

  Иногда мне хотелось бы сказать: «если ни одна из зависимостей не встречается, выберите эту по умолчанию», что позволило бы еще больше автоматизировать процесс.

Также есть эффекты «что-то скрывает другой параметр menuconfig», но это просто пух :-)