Metodología LTP

Absorber LTP (Linux Test Project) y la arquitectura del kernel a base de empolvarse manuales sin tocar código es insufrible. La mejor forma de aprender es mediante práctica guiada y análisis de causa raíz.

Para construir esa metodología de aprendizaje mientras se desarrolla, se propone el siguiente marco de trabajo iterativo:

Metodología de Aprendizaje Práctico en LTP

# Tu código aquí
┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│  1. Ejecución   │───>│  2. Anatómicas  │───>│  3. Inmersión   │
│   y Casuística  │    │   del Test (C)  │    │   en Kernel/libc│
└─────────────────┘    └─────────────────┘    └─────────────────┘
         │                                             │
         └─────────────────────────────────────────────┘
                          4. Refactor / Fix

1. Clasificación de resultados (Casuística)

En lugar de ver las pruebas como un simple “pasa/falla”, serań divididas en tres bloques conceptuales al ejecutarlas:

  • TPASS (Lógica POSIX): Entender por qué pasa (qué llamada al sistema valida y qué estructuras de datos de la glibc/kernel están en juego).

  • TCONF (Límites/Soporte): Como vimos con sysconf01, entender la diferencia entre un fallo y una funcionalidad no implementada o deshabilitada en el kernel de Rocky Linux.

  • TFAIL (Investigación): El plato fuerte. Diagnosticar si es un bug de la prueba, una regresión del kernel, o un problema de entorno/permisos.

2. Anatomía de la prueba (Código fuente en C)

Cuando se elija una llamada al sistema o suite (por ejemplo, process, memory, fs):

  • Revisar la API interna de LTP (tst_test.h, TST_EXP_PASS, etc.).

  • Identificar cómo LTP aísla la prueba (namespaces, cgroups, tst_tmpdir).

3. Inmersión en el Kernel (man 2 + Código fuente)

  • Contrastar lo que exige la prueba con la página de manual del syscall.

  • Si hay dudas de comportamiento, usar herramientas del kernel que ya están configuradas en las reglas de sudoers (trace-cmd, perf, bpftool, o un rastreo rápido con strace).