Cierre y puente a los próximos cursos

1. El punto de llegada

El tema 1 abrió con este programa y con la advertencia de que su única línea útil ponía en marcha más cosas de las que parecía:

#include <stdio.h>

int main(void)
{
    printf("Hola, sistema operativo\n");
    return 0;
}

Entonces describimos lo que ocurría en seis pasos, casi todos con palabras prestadas. Ahora cada parte del programa remite a algo que conocemos:

El programa no cambió. Cambió lo que se ve al mirarlo, y ese era el objetivo del curso: no aprender a usar un sistema operativo, sino saber qué hay debajo de cada programa.

2. El curso en ocho preguntas

El mapa del tema 1 presentaba cada bloque como una pregunta. Estas son las respuestas, en una frase cada una:

3. Las ideas que sostienen todo

De un curso se olvidan los detalles. Conviene decidir qué debe quedar, y son unas pocas ideas que aparecieron una y otra vez, con distintos nombres:

La última no es un concepto de sistemas operativos, sino un método, y quizá sea lo más valioso. Ante una duda sobre lo que hace un programa, la respuesta no está en suponer: está en strace, en /proc o en diez líneas de C escritas para averiguarlo.

4. Los patrones que se repiten

Además de las ideas generales, el curso mostró varias soluciones concretas que reaparecen en lugares distintos. Reconocerlas ahorra mucho esfuerzo al estudiar un sistema nuevo, porque suelen estar ahí también:

5. Los errores, ahora con explicación

En el tema 1 dijimos que estudiar sistemas operativos servía, entre otras cosas, para entender ciertos mensajes de error. Es un buen momento para comprobarlo. Cada uno de estos mensajes resultaba opaco al empezar, y ahora tiene una causa precisa y una forma de investigarlo:

La tabla tiene un rasgo común. En todos los casos, el mensaje es la traducción de un número: un código de errno o una señal. Alguien —el kernel, la shell, la biblioteca— lo convirtió en texto. Saber qué número hay detrás y quién lo produjo es casi siempre la mitad del diagnóstico.

6. La caja de herramientas

El curso no era de administración, pero dejó un conjunto de herramientas probadas. Ordenadas por la pregunta que responde cada una:

Si hubiera que conservar una sola, sería la primera. strace funciona con cualquier programa, en cualquier lenguaje, sin el código fuente, y contesta la pregunta de la que casi todas las demás dependen.

7. Los programas del curso

Cada tema dejó uno o más programas. Reunidos, forman un pequeño laboratorio al que conviene volver: son cortos, cada uno aísla una sola idea, y se prestan a modificarlos.

8. Lo que quedó sin ver

Un curso de fundamentos se define tanto por lo que incluye como por lo que deja para después. En cada bloque hubo que detenerse antes de entrar en profundidad, y conviene tener presente dónde:

La columna derecha no es una lista de omisiones: es el programa de los cursos que siguen. Cada fila tiene el suyo.

9. La ruta: catorce cursos más

Este curso es el primero de quince. Los demás profundizan en lo que aquí se presentó a vista de pájaro, y en cada uno encontrarás como punto de partida algo que ya viste:

Nivel inicial

Nivel intermedio

Nivel avanzado

El orden recomendado es el de los números, pero la ruta no es una fila. Después del nivel inicial, los cursos intermedios pueden tomarse según el interés: quien trabaja con servidores quizá quiera llegar pronto a los sistemas de archivos; quien escribe programas con hilos, a la concurrencia. El último curso es la prueba de todo lo anterior: no hay mejor forma de comprobar que se entiende un sistema operativo que escribir uno.

10. El próximo paso

El curso que sigue es Terminal y Línea de Comandos en Linux. Puede parecer un paso atrás: después de escribir un módulo del kernel, aprender a listar archivos. No lo es. A lo largo de este curso usamos la terminal como un medio, con lo mínimo para llegar a cada experimento, y quedó mucho sin explicar:

La diferencia es que ahora llegas sabiendo qué hay detrás. Para quien empieza por los comandos, ls | wc -l es una fórmula que hay que memorizar. Para ti es una tubería creada por la shell, dos procesos con sus descriptores cambiados entre fork y exec, y un búfer del kernel entre ambos. Los comandos dejan de ser un vocabulario y pasan a ser consecuencias de un modelo que ya tienes. Ese es el sentido de haber empezado por los fundamentos.

11. Cómo seguir practicando

Lo aprendido se fija usándolo. Algunas maneras de hacerlo, de menor a mayor esfuerzo:

• Mirar lo que usas. Elige cada tanto un programa de uso diario y obsérvalo: qué archivos abre, cuántos procesos crea, cuánta memoria ocupa de verdad, qué hace mientras parece no hacer nada. Con strace, ps y /proc alcanza.
• Modificar los programas del curso. Cada tema terminó con ejercicios que proponían cambios. Los que quedaron sin hacer siguen ahí.
• Completar los dos proyectos. La shell del tema 32 admite redirecciones, tuberías y segundo plano. El inspector del tema 33 tiene diez ampliaciones propuestas.
• Leer el manual. man 2 syscalls lista todas las llamadas al sistema. Elegir una desconocida, leer su página y escribir un programa que la use es un ejercicio completo.
• Leer código real. Las utilidades básicas son programas cortos, y su código fuente es público. Ver cómo está escrito el cat o el ls que usaste, después de haber escrito los tuyos, enseña mucho.

Para quien quiera un texto de consulta más amplio, hay cuatro libros que complementan bien este curso:

12. El curso, en doce frases

• Un sistema operativo administra el hardware y lo ofrece a los programas como abstracciones: procesos, memoria propia, archivos.
• El hardware solo ejecuta instrucciones. La protección, el reparto y la multitarea se construyen sobre unas pocas capacidades del procesador.
• El procesador tiene dos modos, y solo el kernel se ejecuta en el privilegiado. Es la base de toda la protección.
• Un programa obtiene servicios del kernel mediante llamadas al sistema: un número, unos argumentos y una instrucción que cambia de modo.
• La biblioteca de C envuelve esas llamadas y añade una capa que las ahorra; POSIX las hace portables entre sistemas tipo Unix.
• El kernel no se ejecuta por su cuenta: lo activan las llamadas al sistema, las interrupciones de los dispositivos y las excepciones del procesador.
• El temporizador garantiza que el kernel recupere el control, y con el cambio de contexto hace posible la multitarea.
• El arranque es una cadena de programas —firmware, cargador, kernel, primer proceso— en que cada uno carga al siguiente.
• Los sistemas operativos se diferencian en lo que priorizan y en cuánto código ponen en modo kernel, no en sus mecanismos básicos.
• El proceso es la unidad a la que se asignan los recursos; su memoria es virtual, y se entrega cuando se usa.
• Archivos, dispositivos y el propio estado del kernel se manejan con la misma interfaz, y el acceso se controla comparando la identidad del proceso con los permisos del recurso.
• Todo lo anterior se puede observar, y esa es la manera de aprenderlo.

13. Autoevaluación final

Estas preguntas no corresponden a un tema: cada una pide relacionar varios. Si puedes responderlas sin consultar, el objetivo del curso está cumplido.

Para terminar

1. Vuelve al tema 1 y relee la sección «El rastro de un "Hola"». Reescríbela con tus palabras y con el detalle que ahora puedes darle.
2. Elige las tres ideas de la sección 3 que te resulten menos claras y repasa los temas indicados.
3. Recorre la tabla de errores de la sección 5 y provoca cada uno a propósito, con un programa o un comando.
4. Completa al menos una ampliación de la shell y una del inspector.
5. Escribe, sin consultar, el recorrido de un comando que elijas, como hicimos en el tema 32. Verifícalo después con strace -f.

Aquí termina Fundamentos de Sistemas Operativos. El sistema que antes era una caja negra tiene ahora un interior conocido: un procesador con dos modos, un kernel que responde, y programas que le piden lo que necesitan. Lo que sigue, en cada curso de la ruta, es abrir una de esas piezas y mirar más de cerca.