Согласно документации 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
зависит от
указывает, что символ (символы) уже должен быть выбран положительно ( = 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
зависит
означает, что опция появляется в меню только в том случае, если выполнены ее предпосылки (булева конструкция, стоящая за ней).
select
означает, что при выборе пользователем этой опции будет автоматически выбрана опция, указанная в качестве аргумента для select
.
Мне нравится думать о том,:
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 не мог разумно выбрать правильную автоматически.
Иногда мне хотелось бы сказать :"если ни одна из зависимостей не соблюдается, выберите эту по умолчанию", хотя это позволило бы еще больше автоматизировать вещи.
Есть также эффекты «что-то скрывает другую опцию в меню конфигурации», но это просто чепуха:-)