1# SDD 22 — Configurador de kernel por niveles: respuesta al handoff de tawasuyu
2
3Escrito 2026-08-07, en respuesta a `tawasuyu/HANDOFF-KERNEL-CONFIG-A-HAMMER.md`.
4
5El handoff avisa de su propio método: *«nada de lo que sigue está verificado contra el código de
6hammer — si un dato de hammer lo contradice, manda hammer»*. Este documento es esa verificación. **No
7es una aprobación ni un plan de implementación**: contesta las seis preguntas de su §9 con evidencia,
8corrige lo que estaba mal, y señala dos objeciones técnicas que cambian el diseño.
9
10**Veredicto corto:** la idea se sostiene y el sustrato está más listo de lo que el handoff supone —
11el mecanismo de §6 (*«la app nunca escribe un `.config`»*) **ya es exactamente como funciona hoy**.
12Pero hay **un hecho estructural que el handoff no podía conocer y que reordena todo**, y **una
13objeción técnica a §2.1** que hay que resolver antes de escribir una línea.
14
15---
16
17## 1. El hecho que reordena todo: **el config ES la identidad del artefacto**
18
19En hammer, `Recipe::hash_inputs` es una lista blanca, y **las fases de build entran en ella**. El
20config del kernel vive dentro de la fase `configure` de `recipes/linux*.toml`. Por lo tanto:
21
22> **Cambiar un solo símbolo de config cambia el `ArtifactHash` del kernel.**
23
24Esto no es un detalle de implementación: es la bisagra del diseño, y corta en los dos sentidos.
25
26**A favor, y fuerte:** §2.2 (config atestado por huella de hardware) **sale casi gratis**. No hay que
27inventar un mecanismo para «atestar un config»: cada config ya *es* un artefacto direccionado por
28contenido, reproducible bit a bit y firmable con la maquinaria que existe. Un «config que booteó en
29esta huella» es, literalmente, un `ArtifactHash` + una firma. El handoff intuyó que hammer tenía el
30sustrato; lo tiene más de lo que creía.
31
32**En contra, y también fuerte:** la explosión de builds que §2.2 quiere evitar **no es hipotética,
33es aritmética visible en el disco**. Cada variante de config es un artefacto nuevo en el store, y el
34store ya crece 24 G por ciclo de trabajo sólo con las variantes que producimos hoy sin querer. Con
35N1 (~40–60 bundles) el espacio combinatorio es 2⁴⁰; con «perfiles publicados» —que es lo que el
36handoff propone en §8— es un puñado. **La restricción de §8 no es una preferencia de diseño: es una
37condición de supervivencia del disco**, y conviene decirlo así en la UI.
38
39**Consecuencia práctica que hay que aceptar desde el día uno:** una «perilla» de la UI **no es un
40parámetro de runtime, es una edición de receta**. No hay forma de tener un config variable sin
41generar recetas. El diseño correcto es que `hammer kernel plan` **emita una receta derivada** (con su
42propio hash) en vez de fingir que el kernel es un binario parametrizable.
43
44---
45
46## 2. Las seis preguntas del §9, contestadas con evidencia
47
48### P1 — ¿Las recetas de kernel aceptan fragmentos o sólo defconfig completo?
49**Ya son fragmentos, y con la forma que §6 prescribe.** `recipes/linux.toml`, fase `configure`:
50
51```
52make ARCH=x86_64 defconfig && \
53scripts/config -d MODULE_SIG -d DEBUG_INFO_BTF -e SECURITY_LANDLOCK -e AUDIT \
54  -d WLAN -d WIRELESS -d CFG80211 -d MAC80211 -d RFKILL  … && \
55make ARCH=x86_64 olddefconfig
56```
57
58Base + deltas por símbolo + resolución por el `olddefconfig` **del propio kernel**. La app nunca
59escribe un `.config`. La única diferencia con el handoff es el vehículo: `scripts/config -e/-d` en
60vez de ficheros de fragmento y `merge_config.sh`. Son equivalentes y `scripts/config` es más fácil de
61generar programáticamente. **Media implementación de §6 ya está en producción.**
62
63Falta la otra mitad, que es la que da la UI veraz: **el diff-back**. Hoy nada comprueba que los
64símbolos pedidos hayan sobrevivido a `olddefconfig`. Un `-e FOO` cuya dependencia no se cumple se
65pierde en silencio — el mismo patrón de fallo que el `license` que caía dentro de `[deps]`.
66
67### P2 — ¿El build es bit-reproducible con config variable?
68**Sí, y por construcción.** El config no es un parámetro externo: es parte de la entrada hasheada
69(§1). Cada config es su propia receta con su propio hash y su propia garantía de reproducción. No hay
70un «kernel» cuya reproducibilidad dependa de congelar el config; hay N kernels, cada uno congelado.
71⇒ **§2.2 puede prefirmar artefactos, no sólo configs.**
72
73### P3 — ¿Cuánto tarda un kernel completo? 🚨
74Declarado en las propias recetas: **`linux` ~35 min, `linux-metal` ~45 min, `linux-generic` ~60 min**
75en la máquina de referencia. En la más lenta del parque, más.
76
77**Esto mata la bisección ingenua de §5.** ~6 rebuilds × 45 min = **4,5 horas** de la máquina del
78usuario para encontrar un bundle culpable. Nadie espera eso, y menos con la máquina que acaba de no
79arrancar. El handoff ya preveía el riesgo («si es caro, tope duro de iteraciones»); la respuesta es
80que **es caro**. Ver §4, donde propongo una bisección que no recompila.
81
82### P4 — ¿harkaq puede prestar su motor de clausura?
83**El patrón sí; el código no.** `crates/hammer-build/src/harkaq.rs` deriva su política enumerando
84**fichero a fichero** los artefactos de las deps declaradas — es una clausura sobre el grafo de
85paquetes materializado en el store, con semántica de rutas de filesystem. Kconfig es otro grafo, con
86otra semántica y ~15 000 símbolos. Reusar la *idea* («política = clausura, no lista») es correcto y
87está validado; reusar la *implementación* no. Hace falta un lector de Kconfig — y ahí está la
88objeción del §3.
89
90### P5 — ¿El índice firmado admite un eje más (la huella)?
91**Sí, y sin romper nada.** `PackageEntry` (`crates/hammer-core/src/repo.rs`) es un struct serde cuyos
92campos opcionales llevan `#[serde(default, skip_serializing_if = ...)]`. Añadir `fingerprint:
93Option<String>` es compatible hacia atrás: los índices viejos siguen parseando y los clientes viejos
94ignoran el campo. **Es exactamente el truco que hizo pagable el campo `license` hoy mismo.**
95
96### P6 — El prerrequisito de PLAN-KIKIN §4.bis
97**Estaba dado por pendiente y está hecho en dos de tres.** Medido:
98
99| receta | `SECURITY_LANDLOCK` | `AUDIT` | `IO_URING` | `BPF_SYSCALL` |
100|---|---|---|---|---|
101| `linux-metal` | ✅ `-e` | ✅ `-e` | ✅ `-e` | ✅ `-e` |
102| `linux-generic` | ✅ `-e` | ✅ `-e` | ✅ `-e` | ✅ `-e` |
103| `linux` | ✅ `-e` | ✅ `-e` | ❌ sólo en un comentario | ❌ sólo en un comentario |
104
105⚠️ Y la forma de medirlo importa: `grep IO_URING recipes/linux.toml` **da positivo** porque la palabra
106aparece en un comentario. Hay que mirar los `-e`/`-d` **dentro del bloque `configure`**. Es el mismo
107error que hoy infló el conteo de licencias (`grep -l license` contaba comentarios y nombres de
108paquete) y el que hace mentir a la regla del `.a` no-PIC. **En este repo, `grep` sobre ficheros con
109comentarios densos no es una medición.**
110
111⇒ Queda pendiente sólo `linux`, que es el kernel de QEMU/serial.
112
113---
114
115## 3. Objeción técnica a §2.1: «clausura» sobre Kconfig no está bien definida todavía
116
117La propuesta —«todo lo alcanzable desde `CONFIG_WIRELESS` menos lo alcanzable desde lo que sí
118quiero»— asume un grafo con aristas de un solo tipo. Kconfig tiene **al menos tres, con semánticas
119incompatibles**:
120
121- `depends on` — arista hacia arriba: *no puedo existir sin X*.
122- `select` — arista hacia abajo y **forzada**: *si yo entro, X entra*, ignorando los `depends on` de
123  X. Es la fuente clásica de configs inválidos.
124- `imply` — sugerencia blanda.
125
126«Alcanzable» por `depends on` y «alcanzable» por `select` dan conjuntos distintos y **ninguno de los
127dos es la respuesta**. Un driver de otro subsistema puede `select` un helper de wireless sin ser
128wireless: cae dentro de la clausura ingenua y apagarlo rompe algo que el usuario sí quería. Y al
129revés, `select` puede meter símbolos wireless desde fuera de la clausura.
130
131**Esto no invalida §2.1 — lo convierte en la parte con contenido técnico real**, tal como el propio
132handoff dice en su §10. Pero hay que definir la semántica de arista antes de escribir el predicado, y
133la definición hay que **validarla contra algo**.
134
135### Y tenemos contra qué validarla, hoy y gratis
136El config actual de `linux.toml` **ya es un juego de bundles N1 escrito a mano**. Literalmente:
137
138```
139-d WLAN -d WIRELESS -d CFG80211 -d MAC80211 -d RFKILL      ← el bundle «no necesito wifi»
140-d SOUND -d SND                                            ← «no necesito audio»
141-d DRM -d DRM_I915 -d DRM_AMDGPU -d DRM_NOUVEAU -d FB      ← «sin gráficos»
142-d XFS_FS -d BTRFS_FS -d F2FS_FS -d JFS_FS -d REISERFS_FS  ← «sólo ext4»
143```
144
145Es un corpus de verdad-de-campo: alguien decidió a mano qué símbolos componen «no necesito wifi», y
146ese kernel **arranca**. La prueba de §2.1 es directa y barata: *¿la clausura calculada de
147`CONFIG_WIRELESS` reproduce ese conjunto?* Si sobra o falta mucho, la semántica de arista está mal y
148nos enteramos en una tarde, sin compilar nada. **Refuerza el §10 del handoff: eso se hace antes que
149nada, junto al modo reversa.**
150
151---
152
153## 4. Lo que agrego: bisección **sin recompilar**
154
155Dado P3 (35–60 min por kernel), la bisección de §5 cuesta horas. Pero la mayoría de los bundles N1
156son **drivers**, y un driver puede ser `=m` en vez de `=y`.
157
158Propuesta: **un kernel «superset» con todo lo bisecable como módulo**. Los bundles N1 de tipo
159hardware no se resuelven entonces recompilando, sino con una **lista de bloqueo de módulos en la
160línea de arranque**. La bisección deja de ser 6 rebuilds (4,5 h) y pasa a ser **6 reinicios**
161(minutos), sobre un kernel que ya está en el árbol de generaciones.
162
163Consecuencias:
164- El «kernel a medida» pasa a ser una optimización de tamaño/arranque, no un requisito de
165  funcionalidad ⇒ el usuario puede probar bundles antes de pagar un build.
166- Encaja con el árbol de generaciones y el rollback E4, que ya existen.
167- **Limitación honesta:** no cubre lo que debe ser `=y` (LSM, preempción, unwinder, `-march`, LTO,
168  o sea buena parte de N2). Para esos sí hay rebuild y sí hay que topar iteraciones.
169- **Y un coste que hay que decir:** el superset es exactamente el kernel gordo que el nivel 1 quiere
170  evitar. Es una herramienta de diagnóstico, no el kernel de todos los días.
171
172## 5. Lo que agrego: el gate de no-regresión (§6) debe ser **por objetivo**, no global
173
174El handoff lo llama la mejor relación valor/esfuerzo y estoy de acuerdo. Pero el config actual de
175`linux.toml` apaga `USB_SUPPORT`, `HID`, `HID_SUPPORT`, `INPUT_MOUSE`, `INPUT_TOUCHSCREEN`. Ese
176kernel **no puede recibir teclado en metal** — y es correcto, porque es el kernel de QEMU con consola
177serie. Un gate global «todo dispositivo en uso debe seguir teniendo driver» **rechazaría una receta
178sana**.
179
180⇒ El gate necesita el objetivo declarado (`qemu-serial` / `metal` / `servidor`) y una noción de
181«dispositivos en uso **de la máquina destino**», que no siempre es la máquina donde se construye.
182Sigue siendo la propuesta más barata de las nueve; sólo que el portón se pone en el sitio correcto.
183
184## 6. Dos huecos del handoff que conviene cerrar antes
185
186**«Booteó» no es una aserción suficiente para atestar (§2.2).** Un kernel puede arrancar y dejarte
187sin red, sin wifi o sin teclado — que es justo el desastre que §6 quiere evitar. Si la atestación
188dice sólo «booteó en esta huella», estamos firmando la clase de fallo que más duele. La atestación
189debería llevar **qué se comprobó**: qué dispositivos de la huella quedaron con driver bindeado
190después de arrancar. Es el mismo dato que ya calcula el gate de §6 ⇒ una implementación, dos usos.
191
192**El catálogo de bundles necesita las tres etiquetas de nivel, no dos.** El handoff avisa en §5 que
193«la mitad de N2 no es Kconfig sino variables de receta». Con §1 en la mano eso es más grave de lo que
194parece: las perillas de receta (LTO, `-march`, `zig_version`) **cambian el hash igual que los
195símbolos**, pero se aplican en otra fase y fallan de otra forma. La UI tiene que saber de qué lado
196cae cada perilla o prometerá diffs que no puede explicar.
197
198---
199
200## 7. Qué contesto al reparto (§7)
201
202De acuerdo con el reparto tal como está. Dos precisiones desde este lado:
203
204- El contrato JSON: de acuerdo, y el precedente que cita (`/run/hammer/boot-graph.json`) es el
205  correcto. Añadiría que el JSON de `hammer kernel plan` **debe incluir el `ArtifactHash` resultante**,
206  porque por §1 el plan *determina* el artefacto: la UI puede decir «esto ya está construido y
207  firmado» sin construir nada.
208- Los verbos propuestos me parecen bien salvo `hammer kernel build --plan`, que esconde dos cosas muy
209  distintas (construir, y dar de alta en el árbol de generaciones). Separarlos deja que la sonda en
210  VM de §4 se meta entre medio como un paso propio y auditable.
211
212## 8. Orden que propongo (modifica el §10 del handoff)
213
2141. **Modo reversa (#9)** — tal cual lo propone: cero riesgo, valida el catálogo contra un kernel real.
2152. **Validar la clausura contra el config actual** (§3 de este documento) — sale gratis, usa un corpus
216   que ya existe, y decide si §2.1 es viable. **Va antes que el gate**, porque si la clausura no
217   reproduce los bundles hechos a mano, el diseño de N1 cambia.
2183. **Gate de no-regresión (#6), por objetivo** (§5 de este documento).
2194. **Diff-back** (la mitad que falta de §6 del handoff): barato, y sin él la UI miente.
2205. Recién después, #1 (clausuras) con la semántica ya decidida.
221
222**No implementar todavía.** Este documento existe para que la decisión se tome con los seis datos
223verificados, no con las suposiciones del handoff — que su autor, correctamente, marcó como tales.
224
225---
226
227# ADENDA — 2026-08-10: implementación en marcha
228
229El usuario decidió. Lo que sigue ya no es análisis: es lo medido contra el código escrito. Se sigue
230el orden del §8.
231
232## 9. Paso 2 hecho: la clausura SÍ reproduce los bundles a mano
233
234`hammer kernel` (`crates/hammer-core/src/kernel/`, `crates/hammer-cli/src/kernel_cmd.rs`) trae un
235lector de Kconfig **de sólo análisis** — la regla dura del §6 del handoff se respeta literalmente: no
236hay solver, el `.config` lo sigue produciendo `olddefconfig`.
237
238Salud del lector, sobre `linux-6.16.12` (`hammer kernel stats`):
239
240| ficheros | símbolos | visibles | con ayuda | aristas `select` | aristas `imply` | avisos de parseo |
241|---|---|---|---|---|---|---|
242| 1646 | 18 212 | 15 169 | 14 866 | 15 165 | 445 | **0** |
243
244### La semántica de arista, resuelta
245El §3 pedía definirla antes de escribir el predicado. Quedó así, y las dos mitades importan:
246
247- **`depends on` en posición conjuntiva** — sólo cuenta como dependencia dura el símbolo que, puesto
248  a `n`, apaga la expresión entera. En `A && (B || C)` sólo `A` es duro; `!X`, las ramas de un `||` y
249  los dos lados de una comparación no aportan nada. Es deliberadamente conservador: preferimos un
250  bundle que apague **de menos** (se nota) a uno que apague de más (hace un ladrillo).
251- **Un símbolo con varias definiciones** muere sólo si mueren todas ⇒ las dependencias duras son la
252  **intersección entre definiciones**, no la unión. El error natural (la unión) diría que apagar `Y`
253  mata a `X` cuando `X` tiene otra definición que ni menciona a `Y`.
254- **`select` no es una arista más: es el portillo.** Fuerza el destino **ignorando** sus
255  `depends on`, así que un símbolo de fuera del bundle reenciende lo que el bundle apagó.
256  `select_leaks` las enumera, y `closure_off_fixpoint` cierra el bundle contra ellas — **reportando
257  el precio, nunca aplicándolo solo**.
258
259### La medición que decide §2.1
260Corpus: el juego de bundles N1 escrito a mano en la fase `configure` de `recipes/linux.toml`, sobre
261un kernel que arranca. Pregunta: *¿la clausura calculada desde la raíz mínima reproduce lo que
262escribió el humano?*
263
264```
265hammer kernel closure --kconfig <árbol> WIRELESS --fixpoint
266```
267
268| | símbolos |
269|---|---|
270| clausura estricta de `WIRELESS` (sólo `depends on`) | 350 |
271| punto fijo (cierra las 3 fugas `select`: `WLAN`, `IWLEGACY`, `GELIC_WIRELESS`) | **406** |
272| bundle `-d WLAN -d WIRELESS -d CFG80211 -d MAC80211 -d RFKILL` hecho a mano | **421** |
273| **sobra** (apagaría algo que el humano dejó vivo) | **0** |
274| **falta** | **15** |
275
276**Sobra cero.** La clausura no toca un solo símbolo que el humano quisiera conservar — que era el
277riesgo real, porque sobrar es hacer un ladrillo. Cierra en **una ronda**.
278
279Los 15 que faltan son **todos de `RFKILL`** (`RFKILL{,_GPIO,_INPUT,_LEDS}` y los drivers de laptop
280que dependen de él: `DELL_RBTN`, `IDEAPAD_LAPTOP`, `MSI_LAPTOP`, `AMILO_RFKILL`…). Y `RFKILL` **no
281es wifi**: es el interruptor de radio compartido, que bluetooth y NFC declaran con el mismo idioma
282(`depends on RFKILL || !RFKILL` en `net/{bluetooth,nfc,wireless}/Kconfig`). Que quede fuera no es un
283fallo de la clausura — es que el humano apagó **dos** bundles a la vez («no necesito wifi» y «no
284necesito radios») y los escribió en la misma línea. ⇒ **el catálogo N1 necesita «sin radios» como
285entrada propia.** Nótese que ese idioma es un `||`: la regla conservadora lo excluye de los duros,
286que es exactamente lo correcto.
287
288⇒ **§2.1 es viable y la objeción del §3 queda resuelta**, con una corrección al diseño: un bundle no
289es `clausura(raíz)` sino **`clausura(raíz)` + el punto fijo sobre `select`**, y las fugas se
290aprueban a mano una vez, no en cada release.
291
292### Y el punto fijo también dice cuándo NO
293No siempre cierra barato, y eso es información, no un fallo. Medido sobre los otros tres bundles a
294mano de `linux.toml`:
295
296| bundle a mano | clausura | fugas `select` | qué las causa |
297|---|---|---|---|
298| `WLAN WIRELESS CFG80211 MAC80211 RFKILL` | 421 | **0** | cerrado |
299| `SOUND SND` | 1323 | 19 sobre 7 destinos | `DRM_I915`/`DRM_NOUVEAU`/`DRM_AMD_DC` hacen `select` del códec HDMI |
300| `DRM DRM_I915 … FB AGP` | 770 | 15 sobre 6 destinos | drivers USB-C (`TYPEC_*`) hacen `select DRM_AUX_BRIDGE` |
301| `XFS_FS BTRFS_FS … NTFS3_FS` | 46 | 1 | `NTFS3_FS ← NTFS_FS` |
302
303Para cerrar «no necesito audio» hay que tragarse drivers gráficos. En `linux.toml` sale gratis
304porque los gráficos también están apagados, pero en un perfil de escritorio **no**: ahí la fuga es
305una decisión, y por eso el punto fijo la muestra en vez de aplicarla.
306
307## 10. Pasos 1 y 4 hechos: modo reversa, plan y diff-back
308
309**Modo reversa** (`hammer kernel probe`) sobre gioser, con el catálogo `docs/state/kernel-bundles.toml`
310(15 bundles N1, 8 perillas N2): 10 551 símbolos declarados, 20 dispositivos PCI, 38 drivers
311bindeados, **7 bundles con capacidad que este hardware no usa**. Y avisa de lo que el propio caso
312destapó: el config vivo es de la serie 7.1 y el catálogo se revisó contra la 6.16 ⇒ las clausuras
313son aproximadas. Se dice en vez de callarlo.
314
315**Plan** (`hammer kernel plan`): emite una **receta derivada**, como manda §1. Medido sobre
316`recipes/linux.toml` con `sin-wifi` + `sin-audio` + `solo-ext4` + `jaula-y-eio-moderna`:
317
318| | |
319|---|---|
320| banderas emitidas | **16** |
321| símbolos que caen con su clausura | **1775** |
322| `ArtifactHash` de la base | `b3:cb926743…` |
323| `ArtifactHash` de la derivada | `b3:47a52b2e…` |
324
325Dos hashes distintos para el mismo código fuente: **el config es la identidad**, y ahora se ve. El
326plan lleva su hash dentro ⇒ la UI puede decir «esto ya está construido y firmado» sin construir.
327
328Tres detalles del plan que no eran obvios:
329- **Se emiten raíces, no clausuras.** 16 banderas, no 1775 líneas. La clausura la calcula el
330  `olddefconfig` del propio kernel; hammer la sabe sólo para poder explicarla.
331- **La fase derivada AÑADE una segunda ronda** (`… && scripts/config … && make olddefconfig`) en vez
332  de reescribir la base. No hay que parsear el shell de nadie y la base sigue siendo literalmente la
333  de siempre en el diff.
334- **Los conflictos se rechazan, no se ordenan.** Dos selecciones que se contradicen sobre un símbolo
335  darían una respuesta plausible y arbitraria según el orden de aparición. Y hay un segundo conflicto
336  que el símbolo solo no delata: encender algo que **cae dentro de la clausura** de lo que otro
337  bundle apaga — `olddefconfig` lo descartaría sin decir nada.
338
339**Diff-back** (`hammer kernel diff-back --plan … --config …`): la mitad que faltaba del §6 del
340handoff. Clasifica cada símbolo pedido en cumplido / **incumplido** (el `.config` dice otra cosa) /
341ausente (el kernel ni lo menciona: la bandera fue un no-op), con la procedencia de quién lo pidió, y
342sale distinto de cero si el config no honra el plan.
343
344### Un hallazgo de regalo
345`recipes/linux.toml` apaga **`REISERFS_FS`, que no existe en 6.16.12** (upstream lo retiró). El
346`scripts/config -d REISERFS_FS` es un no-op que nadie vio. Es exactamente el modo de fallo que el
347**diff-back** (paso 4 del §8) existe para atrapar, encontrado antes de implementarlo: hoy un
348`-e`/`-d` sobre un símbolo inexistente **se pierde en silencio**.