Detección de hardware

Un instalador tradicional le ofrece los mismos diálogos independientemente de si su computadora portátil tiene una iGPU de Intel o una tarjeta NVIDIA; de si trabaja en hardware físico o en una VM; de si su CPU está afectada por RETBleed o no. Se espera que usted lo sepa.

Ditana adapta los diálogos a su hardware. Las elecciones que no le hacen falta se ocultan o se rellenan previamente con valores predeterminados seguros; las que sí le hacen falta aparecen con recomendaciones sensatas.

El principio de detección

Todo el sondeo que alimenta la base de conocimiento está en un único archivo: hardware-detection.kdl. Cada detector es una línea de Raku que se ejecuta una vez al iniciarse el instalador y expone un valor —normalmente un booleano— al resto de la base de conocimiento. El sondeo que necesita más de una línea está en el motor del instalador: allí se coteja la tarjeta gráfica con las listas que publica NVIDIA, y allí también se detectan el formato de bloque NVMe, los medios rotativos y la partición EFI.

Algunos ejemplos representativos del archivo actual:

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

Cada uno lee de /sys/ o /proc/, o recurre al shell para ejecutar una herramienta estándar: sin capa propietaria de abstracción de hardware ni base de datos opaca. Si quiere saber qué detecta Ditana y cómo, la respuesta cabe en una pantalla y no necesita salir del archivo.

De la detección a la decisión

Los detectores no actúan por sí solos. Exponen valores a los que otras opciones hacen referencia en sus expresiones default-value o available. La cadena es siempre: detectar → decidir → instalar.

Un ejemplo claro es la mitigación de vulnerabilidades de la CPU. Cada vulnerabilidad que notifica el kernel (Spectre v2, Meltdown, MDS, TAA, MMIO Stale Data, L1TF, RETBleed, SRSO, GDS, RFDS) tiene su propio detector. La opción de mitigación correspondiente hace referencia entonces a ese detector como su valor predeterminado:

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

Si su CPU no está afectada, la casilla empieza desmarcada. Si lo está, empieza marcada. Nada se filtra según la CPU: todas las mitigaciones aparecen en la lista en ambos casos, así que también puede ver lo que se determinó que su CPU no necesita. Lo único que sí las quita del diálogo es elegir mitigations=off, con lo que ninguna de ellas tiene sentido; consulte cómo dependen las opciones unas de otras. Consulte la página de mitigaciones de CPU para ver la justificación completa de cada vulnerabilidad.

Caso práctico: compatibilidad con Wayland

Algunas detecciones requieren fuentes menos evidentes. Los compositores Wayland modernos como Niri necesitan estrictamente aceleración 3D por hardware: el renderizado por software (llvmpipe, softpipe) no basta; el compositor se cerrará inesperadamente o se negará a iniciarse.

En lugar de deducirlo del fabricante de la GPU, Ditana pregunta al kernel qué controlador DRM está realmente activo para el dispositivo de renderizado:

- 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 el controlador de su sistema no está en esta lista —vmwgfx en VMware, hyperv_fb en Hyper-V, bochs-drm en algunas configuraciones de QEMU—, has-wayland-compatible-gpu se evalúa como False. La opción Niri desaparece de la selección de entornos de escritorio, y Ghostty (que necesita OpenGL 4.3 o posterior, algo que los rasterizadores por software no ofrecen) deja de estar disponible:

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

Un detector, varios consumidores. Agregar más adelante una opción condicionada al hardware suele ser un único cambio en el campo available del consumidor: no hace falta tocar ninguna lógica de detección.