Laboratorio — Entorno de trabajo

Todo el trabajo práctico del curso (tareas en C, simuladores de OSTEP y proyectos en el kernel xv6) se hace dentro de un contenedor Linux idéntico para todos. Así evitamos el “en mi computadora sí funciona”.

1. Requisitos

La imagen es nativa: en una laptop con procesador ARM (Apple Silicon, por ejemplo) corre como ARM, y en una con procesador Intel o AMD corre como x86-64. No hay emulación del contenedor, así que todo es rápido. El único emulador es QEMU, que simula la computadora RISC-V donde arranca xv6.

2. Levantar el contenedor

Desde la carpeta donde van a trabajar:

git clone https://github.com/remzi-arpacidusseau/ostep-homework
git clone https://github.com/remzi-arpacidusseau/ostep-projects
git clone https://github.com/mit-pdos/xv6-riscv

/ruta/al/repo-del-curso/env/run.sh      # la primera vez construye la imagen (unos minutos)

run.sh monta el directorio actual en /work dentro del contenedor. Los archivos se editan con el editor de siempre en su computadora y se compilan y ejecutan en el contenedor. También acepta un comando: run.sh make qemu.

La imagen (env/Dockerfile, Ubuntu 24.04) incluye:

• gcc, make, gdb, valgrind, strace, ltrace, páginas man
• el compilador cruzado riscv64-linux-gnu-gcc y qemu-system-riscv64 (8.2) para xv6
• gdb-multiarch para depurar el kernel
• python3 para los simuladores de OSTEP

run.sh arranca el contenedor con --security-opt seccomp=unconfined. Eso permite usar setarch -R (desactivar la aleatorización de direcciones en las demostraciones de memoria), strace y gdb sin restricciones. Es un contenedor local de práctica; no lo usen así para servicios expuestos.

3. Simuladores de OSTEP

Son scripts de Python 3 que generan problemas y, con -c, muestran la respuesta. La idea es resolver primero a mano y después verificar.

cd /work/ostep-homework/cpu-sched
python3 scheduler.py -p FIFO -j 3 -s 100        # problema
python3 scheduler.py -p FIFO -j 3 -s 100 -c     # respuesta
python3 scheduler.py -h                         # opciones

Cada carpeta tiene un README.md que explica el simulador.

4. xv6

El curso usa xv6-riscv, la versión actual de xv6 que mantiene el MIT. Es un Unix pequeño (unas 6000 líneas de C) que corre sobre RISC-V, una arquitectura de procesador abierta. Lo ejecutamos en QEMU.

cd /work/xv6-riscv
make qemu            # compila y arranca; aparece el prompt "$"

• Salir de QEMU: Ctrl-a y luego x.
• Limpiar: make clean.
• Arrancar con un solo procesador (más fácil de depurar): make qemu CPUS=1.

Depurar el kernel con gdb

Hacen falta dos terminales dentro del mismo contenedor:

# terminal 1
make qemu-gdb              # QEMU queda detenido esperando a gdb

# terminal 2: otra shell en el mismo contenedor
docker exec -it $(docker ps -q --filter name=sistemas-operativos) bash
cd /work/xv6-riscv
gdb-multiarch              # carga .gdbinit y se conecta solo
(gdb) break syscall
(gdb) continue
(gdb) print p->trapframe->a7

gdb-multiarch lee el archivo .gdbinit que genera xv6 y se conecta solo a QEMU. No ejecuten otra vez target remote: QEMU acepta una sola conexión.

Referencias

• Libro de xv6 para RISC-V (MIT, rev. 5)
• Código fuente de xv6-riscv
• Guía de herramientas de MIT 6.1810

5. Probar los proyectos

• P0, P1 y P4 (C en Linux) vienen de ostep-projects. Cada uno trae una carpeta tests/ y un script test-*.sh.
• P2 (lotería en xv6) trae su propio script de pruebas; ver el enunciado.
• P3, P5 y el bono son laboratorios del MIT y se prueban con make grade; ver la guía.

6. Solución de problemas