kernel: el armador de punta a punta — un kernel a medida de gioser, 11,1 MB contra 14,5
Primera vez que el armador se usa para lo que existe, con artefacto real al final:
b3:8ffd57109a2f7102c1bbbbc91cf0e729047312eee1a4e3fdb8b178680cc94264-linux-gioser
linux-metal derivada gioser
bzImage 14,5 MB 11,1 MB (-23%)
símbolos encendidos 1805 1647
diff-back contra el artefacto ... 35 cumplidos, 0 INCUMPLIDOS
gate contra el artefacto ........ ningún dispositivo en uso sin driver
La base la eligió el probe, no la intuición: linux (el de QEMU) apaga USB, HID e INPUT a
propósito y gioser tiene xhci_hcd, usbhid e i8042 bindeados ⇒ linux-metal. 13 bundles y 3
perillas, 34 banderas, clausura de 3054.
Segunda validación de la clausura contra el olddefconfig real, ahora sobre otra base y con
13 bundles: 154 aciertos, SOBRA 0, faltan 18 (todos de la clase «apagado ahora ≠
inalcanzable» del §12).
LA PRUEBA DE 30 s PREDIJO EL BUILD DE 45 MIN. El .config del artefacto y el de la prueba en
seco difieren en 14 líneas y NI UNA es funcional: son las siete versiones del toolchain que
el kernel graba en su propio config (CC_VERSION_TEXT, GCC_VERSION, AS_VERSION, LD_VERSION,
RUSTC_VERSION, RUSTC_LLVM_VERSION, PAHOLE_VERSION). Cero símbolos de diferencia ⇒ la prueba
barata es un sustituto fiel para todo lo que el armador decide.
Y de regalo, la mecánica exacta de por qué el lab TIENE que estar en hash_inputs: el kernel
graba la versión de su compilador DENTRO del .config, y el .config va dentro del artefacto.
No es que el lab «influya» en el resultado — es que el lab está literalmente en el
contenido sellado. Se ve línea a línea: gcc 15.2.0 del lab anclado vs 16.1.1 del host.
PAHOLE_VERSION=0 confirma además lo que dice la cabecera de linux.toml.
La receta derivada NO se deja en recipes/: build-state.py y yupana barren recipes/ y
recipes/incoming-*, así que dejarla ahí la mete en el grafo compartido como deuda. Va en
docs/state/kernel-plans/ con el comando que la regenera; para construir se copia a
recipes/incoming-kernel/ temporalmente y se saca después.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Sergio
@@ -418,6 +418,92 @@ Planear una contra el árbol de la otra calcularía clausuras sobre símbolos qu
|
||||
saldría sin ruido. `KconfigTree` ahora lee su propia versión del `Makefile` de arriba y `plan`
|
||||
**falla** si no coincide con la de la receta (los diagnósticos sólo avisan).
|
||||
|
||||
## 13. Caso de punta a punta: un kernel a medida de gioser (2026-08-11)
|
||||
|
||||
La primera vez que el armador se usa para lo que existe. Máquina: Hetzner vServer, AMD EPYC-Rome,
|
||||
4 vCPU, 20 dispositivos PCI, 38 drivers bindeados.
|
||||
|
||||
**Base: `linux-metal`, no `linux`.** El `probe` decide: `linux` apaga USB, HID e INPUT a propósito
|
||||
(es el kernel de QEMU con consola serie) y gioser tiene `xhci_hcd`, `usbhid` e `i8042` bindeados;
|
||||
`linux-metal` conserva los tres, más virtio, ext4, vfat y EFI. Elegir la base es la primera decisión
|
||||
y el `probe` la contesta con datos, no con intuición.
|
||||
|
||||
**Selección:** 13 bundles y 3 perillas → **34 banderas**, clausura de 3054 símbolos.
|
||||
|
||||
| | símbolos encendidos |
|
||||
|---|---|
|
||||
| `linux-metal` tal cual | 1805 |
|
||||
| derivada para gioser | **1647** (−158) |
|
||||
|
||||
Segunda validación de la clausura contra el `olddefconfig` real, ahora sobre otra base y con 13
|
||||
bundles: **154 aciertos, SOBRA 0**, faltan 18 (todos helpers sin prompt del tipo `DRM_DISPLAY_*`,
|
||||
`CRYPTO_LIB_ARC4` — la misma clase «apagado ahora ≠ inalcanzable» del §12).
|
||||
|
||||
### Lo que sólo se ve midiendo esta máquina
|
||||
El gate contra el `.config` producido, con `/proc/config.gz` de referente, encontró **cuatro
|
||||
pérdidas que ningún bundle causaba**: `aer`, `iTCO_wdt`, `lpc_ich` y `pcspkr` están encendidos en el
|
||||
kernel que corre y **`linux-metal` no los enciende nunca**. No era una regresión del plan: era un
|
||||
hueco de la receta base, invisible para el gate del §11 por construcción.
|
||||
|
||||
Lo mismo con `VIRTIO_BALLOON` y `HW_RANDOM_VIRTIO`: **ninguna receta de kernel del repo los
|
||||
enciende** y en gioser los dos están bindeados. Un kernel de hammer arranca igual en esta máquina,
|
||||
pero la VM se queda sin globo de memoria y sin la entropía del anfitrión.
|
||||
|
||||
⇒ Tres entradas nuevas de catálogo, todas nacidas de medir: bundle `sin-gpu-intel` (i915 es de los
|
||||
drivers más grandes del kernel y en una VM con virtio-gpu no sirve) y perillas `invitado-virtio` y
|
||||
`plataforma-pc`. Con ellas el gate pasa: **✓ ningún dispositivo en uso se queda sin driver.**
|
||||
|
||||
### El artefacto: construido, sellado y verificado
|
||||
|
||||
```
|
||||
b3:8ffd57109a2f7102c1bbbbc91cf0e729047312eee1a4e3fdb8b178680cc94264-linux-gioser
|
||||
```
|
||||
|
||||
| | `linux-metal` | derivada gioser |
|
||||
|---|---|---|
|
||||
| `bzImage` | 14,5 MB | **11,1 MB** (−23%) |
|
||||
| símbolos encendidos | 1805 | 1647 |
|
||||
|
||||
- **diff-back contra el artefacto: 35 cumplidos, 0 incumplidos.**
|
||||
- **gate contra el artefacto** (referente `/proc/config.gz`): ✓ ningún dispositivo en uso se queda
|
||||
sin driver.
|
||||
|
||||
### La prueba de 30 s predijo el build de 45 min
|
||||
El `.config` del artefacto y el de la prueba en seco (§4.bis del runbook) difieren en **14 líneas, y
|
||||
ni una es funcional**: son las siete versiones del toolchain que el kernel graba en su propio
|
||||
config.
|
||||
|
||||
```
|
||||
< CONFIG_CC_VERSION_TEXT="gcc (Alpine 15.2.0) 15.2.0" ← el lab anclado
|
||||
> CONFIG_CC_VERSION_TEXT="gcc (GCC) 16.1.1 20260725" ← el host
|
||||
… GCC_VERSION, AS_VERSION, LD_VERSION, RUSTC_VERSION, RUSTC_LLVM_VERSION, PAHOLE_VERSION
|
||||
```
|
||||
|
||||
Cero símbolos de diferencia. ⇒ **la prueba barata es un sustituto fiel del build** para todo lo que
|
||||
el armador decide.
|
||||
|
||||
Y de regalo, la mecánica exacta de por qué el lab tiene que estar en `hash_inputs`: **el kernel
|
||||
graba la versión de su compilador DENTRO del `.config`**, y el `.config` va dentro del artefacto. No
|
||||
es que el lab «influya» en el resultado — es que **el lab está literalmente en el contenido
|
||||
sellado**. (`PAHOLE_VERSION=0` en el artefacto confirma además lo que dice la cabecera de
|
||||
`linux.toml`: el toolchain del lab no trae pahole.)
|
||||
|
||||
### El paralelismo entra en `hash_inputs`, y hay que saberlo
|
||||
gioser estaba al borde del OOM (swap 3611/4095, 12 `oom-kill` previos) **y hospeda gitea**, en una
|
||||
máquina marcada como fija y sin backup. Bajar el build a `-j1` es lo prudente — y cambia el hash:
|
||||
|
||||
```
|
||||
-j"$(nproc)" b3:10a60ceb…
|
||||
-j1 b3:8ffd5710…
|
||||
```
|
||||
|
||||
El paralelismo **no cambia un byte del `bzImage`**, pero el texto de la fase `compile` está en
|
||||
`hash_inputs`. Por eso el `$(nproc)` de las recetas base no es estilo: mantiene el texto
|
||||
**independiente de la máquina** y evita bifurcar la identidad del artefacto por el número de cores.
|
||||
**Si hay que capar el paralelismo, va FUERA de la receta** (entorno, cgroup, `nice`); editando la
|
||||
fase, cada máquina lenta se fabrica su propio hash. Es el reverso exacto del caso `USB4`: allá
|
||||
cambió el texto y no el `.config`; acá cambia el texto y no el binario.
|
||||
|
||||
### Un hallazgo de regalo
|
||||
`recipes/linux.toml` apaga **`REISERFS_FS`, que no existe en 6.16.12** (upstream lo retiró). El
|
||||
`scripts/config -d REISERFS_FS` es un no-op que nadie vio. Es exactamente el modo de fallo que el
|
||||
|
||||
Reference in New Issue
Block a user