То, каково различие между “выбором” по сравнению с, “зависит” в ядре Linux Kconfig?

Согласно документации Intel Ваш процессор может обработать ОС на 64 бита. Я не думаю единственное преимущество 64 битов, более чем 32 бита повышают предел RAM от ~3.5GB. Поэтому, если Вы не знаете о конкретной причине не использовать версию на 64 бита, я был бы reccomend x86_64.

http://ark.intel.com/products/35635/Intel-Atom-Processor-230-512K-Cache-1_60-GHz-533-MHz-FSB

11
30.03.2018, 13:51
3 ответа

зависит от указывает, что символ (символы) уже должен быть выбран положительно ( = y ), чтобы эта опция быть настроенным. Например, зависит от 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

16
27.01.2020, 19:57

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

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

3
27.01.2020, 19:57

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

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

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

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

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

    Например, в версии 4.15 есть 2 реализации BPF :Classic и Extended.

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

    config BPF_JIT
        depends on HAVE_CBPF_JIT || HAVE_EBPF_JIT
    

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

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

Есть также эффекты «что-то скрывает другую опцию в меню конфигурации», но это просто чепуха:-)

2
27.01.2020, 19:57

Теги

Похожие вопросы