Détection du matériel

Un programme d’installation traditionnel vous propose les mêmes boîtes de dialogue, que votre ordinateur portable ait un iGPU Intel ou une carte NVIDIA, que vous soyez sur une machine physique ou dans une machine virtuelle, que votre processeur soit touché par RETBleed ou non. Vous êtes censé le savoir.

Ditana adapte les boîtes de dialogue à votre matériel. Les choix dont vous n’avez pas besoin sont masqués ou remplis à l’avance avec des valeurs par défaut sûres ; ceux dont vous avez besoin apparaissent avec des recommandations judicieuses.

Le principe de détection

Toutes les opérations de sondage qui alimentent la base de connaissances se trouvent dans un seul fichier : hardware-detection.kdl. Chaque détecteur est une ligne de Raku qui s’exécute une fois au lancement du programme d’installation et expose une valeur – généralement un booléen – au reste de la base de connaissances. Les sondages qui nécessitent plus d’une ligne se trouvent dans le moteur d’installation : la carte graphique y est comparée aux listes que publie NVIDIA, et le format de bloc NVMe, les supports rotatifs et la partition EFI y sont également détectés.

Quelques exemples représentatifs tirés du fichier actuellement utilisé :

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

Chacun lit dans /sys/ ou /proc/, ou fait appel à un outil standard par le shell – pas de couche d’abstraction matérielle propriétaire, pas de base de données opaque. Si vous voulez savoir ce que Ditana détecte et comment, la réponse tient sur un écran et vous n’avez pas besoin de quitter le fichier.

De la détection à la décision

Les détecteurs n’agissent pas d’eux-mêmes. Ils exposent des valeurs auxquelles d’autres paramètres font référence dans leurs expressions default-value ou available. La chaîne est toujours : détecter → décider → installer.

Un exemple clair est l’atténuation des vulnérabilités du processeur. Chaque vulnérabilité signalée par le noyau (Spectre v2, Meltdown, MDS, TAA, MMIO Stale Data, L1TF, RETBleed, SRSO, GDS, RFDS) a son propre détecteur. Le paramètre d’atténuation correspondant fait ensuite référence à ce détecteur comme valeur par défaut :

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

Si votre processeur n’est pas touché, la case à cocher est décochée au départ. S’il l’est, elle est cochée au départ. Rien n’est filtré selon le processeur : chaque mesure d’atténuation est affichée dans tous les cas, ce qui vous permet aussi de voir ce dont votre processeur, d’après la détection, n’a pas besoin. La seule chose qui les retire de la boîte de dialogue est le choix de mitigations=off, qui les rend toutes inutiles – voir comment les paramètres dépendent les uns des autres. Consultez la page sur les mesures d’atténuation du processeur pour la justification complète, vulnérabilité par vulnérabilité.

Étude de cas : compatibilité Wayland

Certaines détections nécessitent des sources moins évidentes. Les compositeurs Wayland modernes comme Niri ont impérativement besoin de l’accélération matérielle 3D – le rendu logiciel (llvmpipe, softpipe) ne suffit pas ; le compositeur plantera ou refusera de démarrer.

Plutôt que de deviner d’après le fabricant du GPU, Ditana demande au noyau quel pilote DRM est réellement actif pour le périphérique de rendu :

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

Si le pilote de votre système ne figure pas dans cette liste – vmwgfx dans VMware, hyperv_fb dans Hyper-V, bochs-drm dans certaines configurations QEMU –, has-wayland-compatible-gpu prend la valeur False. L’option Niri disparaît de la sélection de l’environnement de bureau, et Ghostty (qui nécessite OpenGL 4.3+, inaccessible aux moteurs de rendu logiciel) devient indisponible :

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

Un détecteur, plusieurs consommateurs. Ajouter plus tard une option conditionnée par le matériel se résume généralement à une seule modification dans le champ available du consommateur – aucune logique de détection n’a besoin d’être modifiée.