Rilevamento dell’hardware

Un programma di installazione tradizionale vi offre le stesse finestre di dialogo indipendentemente dal fatto che il vostro portatile abbia una iGPU Intel o una scheda NVIDIA, che vi troviate su hardware fisico o in una VM, che la vostra CPU sia interessata da RETBleed o meno. Si presume che lo sappiate voi.

Ditana adatta le finestre di dialogo al vostro hardware. Le scelte di cui non avete bisogno sono nascoste o precompilate con valori predefiniti sicuri; quelle di cui avete bisogno compaiono con raccomandazioni sensate.

Il principio del rilevamento

Tutti i rilevamenti che alimentano la base di conoscenza si trovano in un unico file: hardware-detection.kdl. Ogni rilevatore è una riga di Raku che viene eseguita una volta all’avvio del programma di installazione ed espone un valore – di solito un valore booleano – al resto della base di conoscenza. I rilevamenti che richiedono più di una riga si trovano nel motore del programma di installazione: lì la scheda grafica viene confrontata con gli elenchi pubblicati da NVIDIA, e sempre lì vengono individuati anche il formato dei blocchi NVMe, i supporti rotativi e la partizione EFI.

Alcuni esempi rappresentativi tratti dal file in uso:

- 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' }"

Ciascuno legge da /sys/, /proc/ oppure richiama tramite shell uno strumento standard – nessun livello di astrazione hardware proprietario, nessun database opaco. Se volete sapere che cosa rileva Ditana e come, la risposta sta in una sola schermata e non dovete uscire dal file.

Dal rilevamento alla decisione

I rilevatori non agiscono da soli. Espongono valori a cui altre impostazioni fanno riferimento nelle loro espressioni default-value o available. La catena è sempre: rilevare → decidere → installare.

Un esempio chiaro è la mitigazione delle vulnerabilità della CPU. Ogni vulnerabilità segnalata dal kernel (Spectre v2, Meltdown, MDS, TAA, MMIO Stale Data, L1TF, RETBleed, SRSO, GDS, RFDS) ha il proprio rilevatore. L’impostazione di mitigazione corrispondente fa poi riferimento a quel rilevatore come proprio valore predefinito:

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

Se la vostra CPU non è interessata, la casella di controllo è inizialmente non selezionata. Se lo è, è inizialmente selezionata. Nulla viene filtrato in base alla CPU: ogni mitigazione viene elencata in entrambi i casi, così potete vedere anche ciò di cui, secondo il rilevamento, la vostra CPU non ha bisogno. L’unica cosa che le rimuove davvero dalla finestra di dialogo è la scelta di mitigations=off, che le rende tutte inutili – consultate come le impostazioni dipendono le une dalle altre. Per le motivazioni complete, vulnerabilità per vulnerabilità, leggete la pagina sulle mitigazioni per la CPU.

Caso di studio: compatibilità con Wayland

Alcuni rilevamenti richiedono fonti meno ovvie. I compositor Wayland moderni come Niri richiedono tassativamente l’accelerazione 3D via hardware – il rendering software (llvmpipe, softpipe) non basta; il compositor si arresta in modo anomalo o si rifiuta di avviarsi.

Anziché tirare a indovinare in base al produttore della GPU, Ditana chiede al kernel quale driver DRM è effettivamente attivo per il dispositivo di rendering:

- 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 }"

Se il driver del vostro sistema non è in questo elenco – vmwgfx in VMware, hyperv_fb in Hyper-V, bochs-drm in alcune configurazioni QEMU – has-wayland-compatible-gpu restituisce False. L’opzione Niri scompare dalla selezione dell’ambiente desktop, e Ghostty (che richiede OpenGL 4.3+, non disponibile con il rendering software) non è più disponibile:

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

Un solo rilevatore, più utilizzatori. Aggiungere in seguito un’opzione che dipende dall’hardware richiede di solito una sola modifica nel campo available dell’utilizzatore – non è necessario toccare alcuna logica di rilevamento.