tawasuyu

tawasuyu/brahman

Rust 582TOML 222Markdown 83JSON 198635 Definitions

⎇ dacfbad1249db14522037f8bcb6792560e1c3047 renaser/ROADMAP.md Markdown · 155 lines · 8.5 KB History raw

feat(renaser): Fase 8d — manipulación de ventanas dacfbad12 · sergio ·

1# renaser — Hoja de ruta
2
3Estado de las fases del proyecto. Para la arquitectura, ver `ARCHITECTURE.md`.
4
5## Fases completadas
6
7Todas verificadas en QEMU (captura de pantalla incluida en su momento).
8
9### Fase 1 — el primer microsegundo
10Arranque UEFI, adopción del framebuffer GOP, lienzo de doble búfer y la baliza
11de pánico (franja roja al colapsar). Punto de entrada con `bootloader_api`.
12
13### Fase 1.5 — empaquetado y arranque
14Miembro `boot/`: constructor de la imagen de disco UEFI (crate `bootloader`
150.11, vía dependencia de artefacto) y lanzador de QEMU. `cargo run` pasa a
16compilar, forjar la imagen y arrancar, todo de un gesto.
17
18### Fase 2.0 — cimientos del manejo de fallos
19GDT propia + TSS con stack de emergencia (IST) para el doble fallo. IDT con
20manejadores de excepción de CPU. El breakpoint es recuperable; el resto de
21excepciones encienden la baliza.
22
23### Fase 2.1 — interrupciones de hardware
24Remapeo del PIC 8259 fuera del rango de las excepciones. Temporizador (PIT) a
25100 Hz e IRQ1 de teclado. El kernel pasa de "pintar una vez" a un bucle de
26render despertado por el hardware.
27
28### Fase 3 — memoria dinámica y reactor asíncrono
29Heap de 64 MiB con `linked_list_allocator` como asignador global; manejador
30propio de OOM (franja naranja). Reactor cooperativo: `Executor`, `Task`,
31`Waker`. Texto vectorial con `fontdue`: el texto deja de ser mapa de bits.
32
33### Fase 4 — el escudo de aislamiento WASM
34Runtime `wasmi` `no_std`. Matriz de capacidades con dos funciones de host
35(`sys_render_frame`, `sys_get_scancode`) y validación infranqueable de límites
36de la memoria lineal. Primera app del userspace: `apps/hello_wasm`, un módulo
37`wasm32` aislado que pinta y responde al teclado.
38
39### Fase 5 — multitarea cooperativa, fuel y reloj
40Unificación del reactor (Fase 3) y el runtime WASM (Fase 4). El ABI del
41userspace pasa a `init`/`tick`: cada `tick` es un punto de cesión cooperativa.
42`async_system::reloj` convierte la IRQ0 en el `Future` `EsperaFrame`, que marca
43el compás de los fotogramas. Cada app es una `AplicacionWasm` persistente y una
44tarea del reactor. Escudo de combustible (`fuel`): cada `tick` corre con un
45presupuesto estricto; agotarlo desaloja la app sin tocar al kernel. Capacidades
46ampliadas — regiones de dibujo por app y canal de teclado por app. Verificado
47en QEMU con tres apps concurrentes, una de ellas díscola y desalojada en vivo.
48
49### Fase 6.0 — cuotas de memoria y ciclo de vida
50Completa el aislamiento espacial del userspace. Cada `AplicacionWasm` instancia
51su `Store` con un `StoreLimits` (techo de memoria lineal de 4 MiB, vía
52`Store::limiter`); rebasarlo es una trampa que desaloja la app con baliza
53amarilla — gemela de la púrpura del desalojo por combustible. `Drop` para
54`AplicacionWasm` reconcilia el ciclo de vida: da de baja el canal de teclado de
55la difusión de la IRQ1. Verificado en QEMU con cuatro apps — una díscola
56(desalojo temporal) y una glotona (desalojo espacial), ambas en vivo.
57
58## Fase 6.1 — sustrato de almacenamiento (completada)
59
60Estrategia incremental para el almacenamiento, frente al riesgo del hardware:
61
62- **6.1a — Sonda PCI** *(hecha)* — `drivers/pci.rs` enumera el bus PCI por
63  `0xCF8`/`0xCFC` y localiza el disco virtio-blk; `boot` forja el disco de
64  pruebas y lo adjunta como `virtio-blk-pci`. El muro del descubrimiento de
65  hardware queda derribado.
66- **6.1b — HAL y lectura de sector** *(hecha)* — `drivers/disco.rs`: asignador
67  de marcos «bump», `KernelHal` (el `trait Hal` de `virtio-drivers`: DMA y
68  traducción de direcciones) y `montar_y_leer_sector0`, que lee el sector 0 por
69  sondeo. Verificado por una firma que viaja del anfitrión al disco y vuelve.
70- **6.1c — Grafo de objetos** *(hecha)* — `almacen.rs`: el almacenamiento como
71  DAG direccionado por contenido —la identidad de un objeto es el hash BLAKE3
72  de su forma serializada (`postcard`); el disco se organiza como un log con
73  superbloque e índice—, y las cinco capacidades `sys_object_*` que lo exponen
74  al userspace. `drivers/disco.rs` gana un asignador de marcos con liberación
75  real (mapa de bits), escritura de sectores y un `VirtIOBlk` persistente. La
76  app `cronista` lleva la cuenta de los arranques en el grafo: la cuenta
77  perdura entre reinicios.
78
79## Fase 6.2 — E/S de disco asíncrona por interrupción (completada)
80
81La Fase 6.1 hizo hablar al disco, pero por **sondeo**: el procesador se quedaba
82en espera activa vigilando el *used ring* de virtio. La 6.2 libera el
83planificador cooperativo — la E/S de bloques pasa a ser **reactiva**:
84
85- `EsperaDisco` — una transferencia de bloques como `Future` nativo, sobre la
86  API no bloqueante de `virtio-drivers` (`read_blocks_nb` / `peek_used` /
87  `complete_*`). Cede la CPU mientras el disco trabaja.
88- La **IRQ del disco** — `montar` descubre la línea de IRQ legada del
89  dispositivo (registro «Interrupt Line» del espacio de configuración PCI), la
90  enruta por el 8259 y registra su manejador; `atender_irq` reconoce la
91  interrupción y despierta a la tarea que aguardaba el bloque.
92- `bloquear_en` — el puente para los contextos síncronos (el arranque, las
93  capacidades WASM): duerme la CPU con `hlt` en vez de sondear.
94
95Decisión de ingeniería: las IRQ se enrutan por el **PIC 8259** que el kernel ya
96gobierna, no por el IOAPIC — basta leer la línea que el firmware ya asignó.
97Verificado en QEMU: el disco se enruta a la IRQ 11; una tarea-sonda del reactor
98lee un bloque de forma asíncrona mientras las apps siguen pintando.
99
100## Fase 7 — el userspace nace del Grafo de Objetos (completada)
101
102Hasta la Fase 6, el userspace venía **empotrado en el binario del kernel**:
103cuatro `include_bytes!` de `.wasm` y regiones escritas a mano. La Fase 7 lo
104destierra — las aplicaciones pasan a ser objetos del grafo, gobernadas por un
105**Manifiesto de Génesis** que también vive en el grafo. Plan completo en
106`FASE7.md`.
107
108- **7a — el Manifiesto (completada).** `manifiesto.rs`: tipos `Manifiesto` /
109  `EntradaApp` y carga desde el grafo. El superbloque gana el ancla
110  `manifiesto` (VERSION 1→2). `kernel_main` lee el manifiesto e instancia cada
111  app recuperando su bytecode del grafo, verificado por su hash.
112- **7b — la imagen sembrada por `boot` (completada).** Nace la crate
113  `formato`, un núcleo `no_std` con el formato del grafo en disco, COMPARTIDO
114  por el kernel y el constructor de imagen `boot`. `boot` siembra el disco
115  virgen con el grafo ya poblado —bytecode y manifiesto—; el kernel pierde
116  todo `include_bytes!` del userspace. Su binario ya no carga ni un `.wasm`.
117- **7c — persistencia inter-sesión (completada).** La app `memoriosa` graba
118  su estado como un objeto del grafo; el kernel lo ancla en la ranura
119  `EntradaApp.estado` y re-graba el manifiesto. Al despertar, `init` lo relee
120  y la app retoma donde quedó. Capacidades `sys_estado_cargar` /
121  `sys_estado_guardar`; el kernel custodia un manifiesto VIVO y mutable.
122
123## Fase 8 — el compositor teselante e interactivo (completada)
124
125El kernel deja de colocar las ventanas a mano: las **tesela**. El motor es
126`mirada-layout` —el mismo núcleo `no_std` que ordena el compositor Wayland de
127brahman—, enlazado por `path` cruzando la frontera de workspace. Plan completo
128en `FASE8.md`.
129
130- **8a — el compositor tesela (completada).** `compositor.rs` calcula un marco
131  por app con el algoritmo `MasterStack`. El kernel centra el fotograma natural
132  de cada app dentro de su marco; las apps no cambian una instrucción.
133  `region_x/y` del manifiesto quedan vestigiales — la posición la decide el
134  compositor.
135- **8b — teselado interactivo (completada).** `Alt+Espacio` cicla los modos de
136  teselado en caliente. El kernel cachea el último fotograma de cada app y
137  recompone desde la caché: las apps estáticas sobreviven al re-teselado sin
138  enterarse del cambio.
139- **8c — foco y enrutamiento selectivo (completada).** Una ventana enfocada,
140  con borde índigo; `Alt+J` / `Alt+K` mueven el foco entre las ventanas vivas.
141  El teclado deja de difundir: entrega cada tecla sólo a la app enfocada.
142- **8d — manipulación de ventanas (completada).** El orden de teselado se
143  separa de la identidad de las ventanas. `Alt+Enter` promueve la ventana
144  enfocada a la celda maestra; `Alt+H` / `Alt+L` la reordenan. El foco viaja
145  con la ventana.
146
147Líneas abiertas posteriores: orden-Z y ventanas flotantes; más capacidades del
148host (temporización, audio).
149
150## Principios que persisten entre fases
151
152- Reutilizar infraestructura madura de la comunidad antes que reinventar.
153- `unsafe` mínimo, confinado y justificado.
154- Verificar cada fase en QEMU antes de cerrarla.
155- `git commit` + `git push` tras cada iteración.

ROADMAP.md

renaser — Hoja de ruta

Estado de las fases del proyecto. Para la arquitectura, ver ARCHITECTURE.md.

Fases completadas

Todas verificadas en QEMU (captura de pantalla incluida en su momento).

Fase 1 — el primer microsegundo

Arranque UEFI, adopción del framebuffer GOP, lienzo de doble búfer y la baliza de pánico (franja roja al colapsar). Punto de entrada con bootloader_api.

Fase 1.5 — empaquetado y arranque

Miembro boot/: constructor de la imagen de disco UEFI (crate bootloader 0.11, vía dependencia de artefacto) y lanzador de QEMU. cargo run pasa a compilar, forjar la imagen y arrancar, todo de un gesto.

Fase 2.0 — cimientos del manejo de fallos

GDT propia + TSS con stack de emergencia (IST) para el doble fallo. IDT con manejadores de excepción de CPU. El breakpoint es recuperable; el resto de excepciones encienden la baliza.

Fase 2.1 — interrupciones de hardware

Remapeo del PIC 8259 fuera del rango de las excepciones. Temporizador (PIT) a 100 Hz e IRQ1 de teclado. El kernel pasa de "pintar una vez" a un bucle de render despertado por el hardware.

Fase 3 — memoria dinámica y reactor asíncrono

Heap de 64 MiB con linked_list_allocator como asignador global; manejador propio de OOM (franja naranja). Reactor cooperativo: Executor, Task, Waker. Texto vectorial con fontdue: el texto deja de ser mapa de bits.

Fase 4 — el escudo de aislamiento WASM

Runtime wasmi no_std. Matriz de capacidades con dos funciones de host (sys_render_frame, sys_get_scancode) y validación infranqueable de límites de la memoria lineal. Primera app del userspace: apps/hello_wasm, un módulo wasm32 aislado que pinta y responde al teclado.

Fase 5 — multitarea cooperativa, fuel y reloj

Unificación del reactor (Fase 3) y el runtime WASM (Fase 4). El ABI del userspace pasa a init/tick: cada tick es un punto de cesión cooperativa. async_system::reloj convierte la IRQ0 en el Future EsperaFrame, que marca el compás de los fotogramas. Cada app es una AplicacionWasm persistente y una tarea del reactor. Escudo de combustible (fuel): cada tick corre con un presupuesto estricto; agotarlo desaloja la app sin tocar al kernel. Capacidades ampliadas — regiones de dibujo por app y canal de teclado por app. Verificado en QEMU con tres apps concurrentes, una de ellas díscola y desalojada en vivo.

Fase 6.0 — cuotas de memoria y ciclo de vida

Completa el aislamiento espacial del userspace. Cada AplicacionWasm instancia su Store con un StoreLimits (techo de memoria lineal de 4 MiB, vía Store::limiter); rebasarlo es una trampa que desaloja la app con baliza amarilla — gemela de la púrpura del desalojo por combustible. Drop para AplicacionWasm reconcilia el ciclo de vida: da de baja el canal de teclado de la difusión de la IRQ1. Verificado en QEMU con cuatro apps — una díscola (desalojo temporal) y una glotona (desalojo espacial), ambas en vivo.

Fase 6.1 — sustrato de almacenamiento (completada)

Estrategia incremental para el almacenamiento, frente al riesgo del hardware:

Fase 6.2 — E/S de disco asíncrona por interrupción (completada)

La Fase 6.1 hizo hablar al disco, pero por sondeo: el procesador se quedaba en espera activa vigilando el used ring de virtio. La 6.2 libera el planificador cooperativo — la E/S de bloques pasa a ser reactiva:

Decisión de ingeniería: las IRQ se enrutan por el PIC 8259 que el kernel ya gobierna, no por el IOAPIC — basta leer la línea que el firmware ya asignó. Verificado en QEMU: el disco se enruta a la IRQ 11; una tarea-sonda del reactor lee un bloque de forma asíncrona mientras las apps siguen pintando.

Fase 7 — el userspace nace del Grafo de Objetos (completada)

Hasta la Fase 6, el userspace venía empotrado en el binario del kernel: cuatro include_bytes! de .wasm y regiones escritas a mano. La Fase 7 lo destierra — las aplicaciones pasan a ser objetos del grafo, gobernadas por un Manifiesto de Génesis que también vive en el grafo. Plan completo en FASE7.md.

Fase 8 — el compositor teselante e interactivo (completada)

El kernel deja de colocar las ventanas a mano: las tesela. El motor es mirada-layout —el mismo núcleo no_std que ordena el compositor Wayland de brahman—, enlazado por path cruzando la frontera de workspace. Plan completo en FASE8.md.

Líneas abiertas posteriores: orden-Z y ventanas flotantes; más capacidades del host (temporización, audio).

Principios que persisten entre fases