Виявлення обладнання

Традиційний інсталятор пропонує вам ті самі діалогові вікна незалежно від того, чи має ваш ноутбук iGPU від Intel або відеокарту NVIDIA; чи працюєте ви на фізичному обладнанні або у віртуальній машині; чи зачіпає ваш процесор вразливість RETBleed, чи ні. Від вас очікують, що ви це знаєте.

Ditana адаптує діалогові вікна до вашого обладнання. Варіанти вибору, які вам не потрібні, приховано або заздалегідь заповнено безпечними типовими значеннями; ті, що справді потрібні, з’являються з розумними рекомендаціями.

Принцип виявлення

Усі перевірки, що постачають дані базі знань, містяться в одному файлі: hardware-detection.kdl. Кожен детектор — це один рядок Raku, який виконується один раз під час запуску інсталятора й надає значення — зазвичай логічне — решті бази знань. Перевірки, яким не досить одного рядка, містяться в рушії інсталятора: там відеокарту звіряють зі списками, які публікує NVIDIA, і там же визначають формат блоків NVMe, обертові носії та розділ EFI.

Кілька показових прикладів з актуального файлу:

- name="uefi" \
  detect="'/sys/firmware/efi'.IO.e"

- name="intel-cpu" \
  detect="'/proc/cpuinfo'.IO.lines.first(* ~~ /vendor_id/).contains('GenuineIntel')"

- name="virtual-environment" \
  detect="run('systemd-detect-virt', '-q').exitcode eq 0"

- name="is-retbleed-vulnerable" \
  detect="given '/sys/devices/system/cpu/vulnerabilities/retbleed'.IO
            { .e && .slurp.chomp ne 'Not affected' }"

Кожен із них читає з /sys/, /proc/ або викликає через оболонку стандартний інструмент — жодного власницького шару абстракції обладнання, жодної непрозорої бази даних. Якщо ви хочете знати, що виявляє Ditana і як, відповідь уміщується на одному екрані, і вам не потрібно виходити за межі файлу.

Від виявлення до рішення

Детектори самі нічого не роблять. Вони надають значення, на які інші налаштування посилаються у своїх виразах default-value або available. Ланцюжок завжди такий: виявити → вирішити → встановити.

Наочний приклад — захист від вразливостей процесора. Кожна вразливість, про яку повідомляє ядро (Spectre v2, Meltdown, MDS, TAA, MMIO Stale Data, L1TF, RETBleed, SRSO, GDS, RFDS), має власний детектор. Відповідне налаштування засобу захисту (mitigation) потім використовує цей детектор як своє типове значення:

- name="kernel-option-retbl" \
  dialog-name="CPU Vulnerability Mitigation Options" \
  short-description="Enforce Retbleed Mitigation (retbleed=auto,nosmt)" \
  default-value="`is-retbleed-vulnerable`"

Якщо ваш процесор не вразливий, прапорець спочатку не позначений. Якщо вразливий — спочатку позначений. За процесором нічого не відфільтровується: кожен засіб захисту показано в будь-якому разі, тож ви бачите й те, що вашому процесору, як виявилося, не потрібно. Єдине, що справді прибирає їх із діалогового вікна, — вибір mitigations=off, який робить кожен із них безглуздим, — див. як налаштування залежать одне від одного. Повне обґрунтування для кожної вразливості див. на сторінці Захист від вразливостей процесора.

Практичний приклад: сумісність із Wayland

Для деяких перевірок потрібні менш очевидні джерела. Сучасні композитори Wayland, як-от Niri, обов’язково потребують апаратного 3D-прискорення — програмного рендерингу (llvmpipe, softpipe) недостатньо: композитор аварійно завершить роботу або відмовиться запускатися.

Замість того щоб здогадуватися за виробником GPU, Ditana запитує в ядра, який драйвер DRM справді активний для пристрою рендерингу:

- name="has-wayland-compatible-gpu" \
  detect="given dir('/sys/class/drm').grep(*.basename.starts-with('renderD')).first
            { $_ ?? ($_ ~ '/device/driver').IO.resolve.basename
                    ~~ any(<amdgpu radeon i915 xe nvidia nouveau virtio-pci virtio_gpu>)
                  !! False }"

Якщо драйвера вашої системи немає в цьому списку — vmwgfx у VMware, hyperv_fb у Hyper-V, bochs-drm у деяких конфігураціях QEMU, — has-wayland-compatible-gpu набуває значення False. Варіант Niri зникає з вибору стільничного середовища, а Ghostty (якому потрібен OpenGL 4.3+, недоступний для програмних засобів растеризації) стає недоступним:

- name="install-ghostty" \
  available="`install-desktop-environment AND has-wayland-compatible-gpu`"

Один детектор — багато споживачів. Щоб пізніше додати параметр, доступність якого залежить від обладнання, зазвичай досить однієї зміни в полі available споживача — логіку виявлення змінювати не потрібно.