Qué es un kernel
En la lección anterior vimos que un programa pide en un mostrador oficial, la llamada al sistema, y que la CPU pasa por un momento a modo núcleo en cuanto la petición cruza. Entonces, ¿quién hace de verdad el trabajo tras ese mostrador, con ese privilegio fuerte? ¿Y por qué ese modo lleva el nombre de núcleo? Esta vez conocemos cara a cara el centro más profundo del sistema operativo, la pieza que nunca abandona su puesto.
¿Quién está detrás del mostrador?
Recordemos la lección anterior. Un programa vive tras una cerca y no puede tocar el hardware, así que cuando necesita algo lo pide en el mostrador oficial llamado llamada al sistema. En cuanto la petición cruza, la CPU pasa un momento a modo núcleo, hace el trabajo y vuelve.
Hubo algo que dejamos sin mirar a propósito: quién, detrás del mostrador, hace de verdad el trabajo con ese privilegio fuerte.
El mostrador es solo la entrada donde se reciben las peticiones. Más adentro hay un trabajador aparte que de verdad lee el disco y enciende puntos en la pantalla. Ese trabajador es el núcleo, al que casi todo el mundo llama kernel.
Pulsa el botón y la casilla oculta detrás del mostrador de llamadas al sistema se abre y deja ver el kernel. Quien atendía de verdad la petición del programa era el kernel desde el principio.
Ahora el nombre de modo núcleo tiene sentido. Ese privilegio fuerte es la fuerza que usa el kernel mientras trabaja, y por eso el modo lleva su nombre.
Entonces, ¿aparece el kernel solo un instante cuando llega una petición y luego desaparece? Para nada.
Cuando se habla de sistema operativo en el sentido más estricto, muchas veces se habla de este kernel.
Desde cuándo y hasta cuándo está el kernel en su puesto es lo que sigue.
El kernel siempre está despierto
Las apps que usamos se abren y se cierran. Abrimos una app de música y la cerramos, arrancamos un navegador y salimos de él. Una app se carga en memoria cuando hace falta y se retira cuando se cierra.
El kernel es distinto. Se carga en memoria mientras la computadora arranca, se instala en su sitio y no lo abandona ni una vez hasta que se corta la corriente. Por muchas apps que entren y salgan, el kernel sigue despierto por debajo de ellas.
Pensándolo bien, es lo lógico. Cargar apps en memoria y retirarlas, decidir quién usa la CPU: todo eso lo hace el kernel. Si el kernel se durmiera, no quedaría nadie para hacerlo.
Cada una de las tres casillas de apps de arriba se enciende y se apaga al pulsarla, pero la casilla del kernel, abajo del todo, sigue encendida todo el tiempo. El kernel permanece en memoria desde el arranque hasta el apagado.
Las casillas de las apps parpadearon, pero la del kernel siguió encendida sin cambios. El kernel se parece al tramoyista que sube y baja el telón: los actores entran y salen, pero él sigue en su puesto durante toda la función.
Entonces, ¿qué hace exactamente el kernel desde ese puesto? En realidad, casi todo lo que vimos en esta área ha estado funcionando en sus manos.
La torre de control de todos los recursos
A lo largo de esta área aprendimos muchas cosas: la planificación, que decide quién usa la CPU a continuación; la memoria virtual, que hace que la memoria parezca más grande de lo que es; los controladores, que permiten hablar con un dispositivo nuevo; el sistema de archivos, que mantiene los archivos en orden; y la comprobación de permisos, que decide quién puede hacer qué.
Las vimos una por una, pero una sola mano hace todo ese trabajo: el kernel.
El kernel se parece a la torre de control de un aeropuerto. Igual que la torre decide desde un solo lugar cuándo despega y aterriza cada avión y qué pista usa, el kernel decide desde un solo lugar cuánto de cada recurso, la CPU, la memoria, los dispositivos y los archivos, recibe cada quien.
Pulsa cualquiera de los cinco recursos y se ilumina la casilla del kernel en el centro. Sea la planificación de CPU, la memoria, los controladores, los archivos o los permisos, quien se encarga es siempre el kernel.
Pulsaras el recurso que pulsaras, el camino llevaba al kernel. Las tareas que parecían dispersas giraban en torno a un solo centro.
Pero si el kernel hace todo este trabajo tan poderoso, ¿no es peligroso? Sería un desastre que cualquier programa pudiera usar ese poder.
Por eso la computadora divide el mundo del poder en dos.
La frontera entre dos modos
Recordemos los dos modos de la lección anterior. El modo usuario es el mundo limitado donde viven nuestras apps. El modo núcleo es el mundo donde trabaja el kernel y donde se puede tocar directamente el hardware y todo lo demás.
Entre los dos hay una frontera clara. Una app en modo usuario no puede llegar al hardware; solo el kernel, trabajando en modo núcleo, lo toca directamente. Por eso, cuando una app intenta hacer algo por su cuenta, se la frena, y el trabajo solo se hace cuando la app se lo pide al kernel y la tarea pasa por el modo núcleo.
Gracias a esa frontera, el poder fuerte se concentra en un único lugar de confianza: el kernel.
Usa el botón de la izquierda para cambiar de modo y el de la derecha para intentar llegar directamente al hardware. En modo usuario queda bloqueado (rojo); solo en modo núcleo se permite (verde). El poder fuerte solo vive dentro del modo núcleo.
En modo usuario quedó bloqueado y solo pasó en modo núcleo. Que el poder fuerte se concentre en el kernel da tranquilidad: las acciones peligrosas pasan por un solo lugar, así que basta con vigilar ese lugar.
Al mismo tiempo surge una idea inquietante. Si todo depende del kernel, ¿qué pasa cuando el propio kernel tiene un problema?
Cuando el kernel se detiene
Reunamos lo que hemos visto. El kernel es el programa central que hace el trabajo real detrás del mostrador de llamadas al sistema; permanece en memoria desde el arranque hasta el apagado, y administra con una sola mano todos los recursos: la CPU, la memoria, los dispositivos, los archivos y los permisos. El modo núcleo, con su privilegio fuerte, es la fuerza que usa mientras trabaja.
Por eso, cuando una app falla y se congela o se cierra de golpe, el kernel que está por debajo sigue vivo: esa app se limpia y las demás siguen funcionando. Gracias a eso podemos forzar el cierre de una app colgada y seguir usando la computadora.
Si el que se detiene es el propio kernel, la historia cambia por completo. Desaparece la única mano que limpia las apps, reparte los recursos y atiende las peticiones, así que todas las apps de encima y el sistema entero se paran a la vez. Esos raros momentos en que la pantalla se pone azul de repente o nada responde y hay que reiniciar son justo cuando el kernel ya no pudo aguantar. La pantalla azul de error de Windows y el kernel panic de Linux son justo eso.
Pulsa una de las tres apps y solo esa se detiene; las demás siguen bien. Después pulsa el botón de detener el kernel, abajo, y todo lo que hay encima se para de golpe (rojo).
El centro del sistema operativo ya se ve con claridad. La planificación, la memoria, los controladores, los archivos, los permisos y las llamadas al sistema que estudiamos por separado funcionaban todos en la mano de este kernel.
Sin embargo, repartir recursos desde una sola mano trae un problema nuevo. Si dos programas se aferran cada uno a lo que tienen y solo esperan lo que tiene el otro, los dos pueden quedarse parados para siempre.
La próxima lección trata de ese interbloqueo (deadlock), el que ocurre cuando ninguno de los dos cede.