Яка різниця між "виділити" проти "залежить" в ядрі Linux Kconfig?

Чим відрізняються залежності між файлами Kconfig selectта depends onв ядрах?

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_JITфункція залежить від принаймні однієї з включених реалізацій:

  config BPF_JIT
      depends on HAVE_CBPF_JIT || HAVE_EBPF_JIT
  

  Оскільки є дві можливі реалізації для BFP_JIT, Kconfig не міг розумно вибрати правильну автоматичну.

  Іноді я хотів би сказати: "якщо жодна із залежностей не виконана, виберіть цю за замовчуванням", хоча це дозволить додатково автоматизувати речі.

Є також "щось приховує інший варіант меню Menuffig", але це просто пух :-)