System Calls (Llamadas al Sistema)
Llamadas al sistema en sistemas operativos: mecanismo trap, pasos de ejecución, el estándar POSIX y la interfaz entre programas y kernel.
Tesis
Las llamadas al sistema (system calls) son el mecanismo mediante el cual los programas de usuario solicitan servicios al sistema operativo: el puente entre los programas y el kernel para operaciones como leer archivos, crear procesos o gestionar memoria. Se estudian como la interfaz entre los programas de usuario y el SO — la forma de comprender qué hace un sistema operativo.
Desglose del mecanismo
El trap (instrucción de trampa)
Un proceso en modo usuario que necesita un servicio del kernel (ej. leer un archivo) ejecuta una instrucción de trampa (trap) — en x86-64, la instrucción SYSCALL — que cambia de modo usuario a modo kernel y transfiere el control a una dirección fija dentro del kernel.
Pasos de ejecución
- La aplicación prepara los parámetros en registros (RDI, RSI, RDX en x86-64; RCX, R8, R9 completan los seis primeros argumentos; los adicionales van en la pila).
- Llama a la función de biblioteca (ej.
read). - La biblioteca coloca el número de llamada en el registro RAX.
- Ejecuta
SYSCALL(trap) para entrar al kernel. - El kernel examina el número de llamada y lo despacha al manejador correcto mediante una tabla de punteros indexada por ese número.
- El manejador ejecuta la operación solicitada.
- El control regresa a la biblioteca en espacio de usuario.
- La biblioteca retorna al programa de usuario.
Una llamada al sistema se parece a una llamada a procedimiento especial que entra al kernel.
Ejemplo: read
- Tres parámetros: archivo, búfer y número de bytes a leer. El búfer se pasa por referencia (su dirección).
- Desde C:
read(fd, buffer, nbytes);— la función de biblioteca con el mismo nombre envuelve la llamada. - Devuelve el número de bytes leídos o un valor < 0 ante error; el código de error queda en la variable global
errno. El programa debe verificar si hubo error tras cada llamada.
Bloqueo
Una llamada al sistema puede bloquear al proceso (ej. esperar entrada del teclado). En ese caso el SO selecciona otro proceso listo para ejecutarse mientras espera.
POSIX
El estándar POSIX define aproximadamente 100 llamadas para crear/terminar procesos, manejar archivos/directorios y realizar E/S. No obstante:
- POSIX no especifica si una función debe ser llamada al sistema o de biblioteca — solo exige que esté disponible.
- Si una función puede ejecutarse en espacio de usuario, se prefiere por rendimiento.
- Varias funciones de biblioteca pueden compartir una misma llamada al sistema (variaciones menores entre sí).
Q&A de referencia
Interfaz y mecanismo
- ¿Cuáles son las dos funciones principales del SO? Proveer abstracciones a los programas de usuario y administrar los recursos del computador.
- ¿Con qué parte del SO interactúan principalmente los programas? Con las abstracciones que provee.
- ¿La gestión de recursos es visible para el usuario? No, generalmente es transparente y automática.
- ¿Qué interfaz se analiza para comprender el SO? La interfaz entre los programas de usuario y el sistema operativo.
- ¿Varían las llamadas entre SO? Sí, pero los conceptos subyacentes son similares.
- ¿Qué enfoque se eligió para explicarlas? El enfoque específico, usando POSIX y sistemas como UNIX, Linux y MINIX 3.
- ¿Qué permite una biblioteca de procedimientos? Realizar llamadas al sistema desde C y otros lenguajes.
- ¿Qué debe hacer un proceso en modo usuario para solicitar un servicio? Ejecutar una instrucción de trampa (trap).
- ¿Qué hace el SO al recibir una llamada? Inspecciona los parámetros, ejecuta la llamada y retorna el control al proceso.
- ¿A qué se parece una llamada al sistema? A una llamada a procedimiento especial que entra al kernel.
- ¿Cómo se invoca desde C? Llamando a una función de biblioteca con el mismo nombre:
read(fd, buffer, nbytes);. - ¿Qué devuelve
read? El número de bytes leídos o un valor < 0 ante error. - ¿Dónde se guarda el número de error? En la variable global
errno. - ¿Qué debe hacer un programa tras una llamada? Verificar si ocurrió un error.
- ¿Dónde se almacenan los parámetros en x86-64? En RDI, RSI, RDX, RCX, R8 y R9.
- ¿Qué pasa con más de seis argumentos? Se almacenan en la pila.
- ¿Cómo se pasa el parámetro del búfer en
read? Por referencia (la dirección del búfer). - ¿Qué hace la biblioteca antes de la trampa? Coloca el número de llamada en RAX.
- ¿Qué instrucción cambia de modo usuario a kernel en x86-64?
SYSCALL. - ¿A qué dirección salta la trampa? A una dirección fija dentro del kernel.
- ¿Qué hace el kernel tras recibir la trampa? Lee el número de llamada y salta al manejador correspondiente.
- ¿Cómo se invoca el manejador? Vía una tabla de punteros indexada por el número de llamada.
- ¿Qué ocurre tras ejecutar el manejador? El control regresa a la función de biblioteca y luego al programa de usuario.
- ¿Puede una llamada bloquear al proceso? Sí, p. ej. si espera entrada del teclado.
- ¿Qué hace el SO cuando un proceso se bloquea? Busca otro proceso para ejecutar mientras espera.
POSIX
- ¿Cuántas llamadas POSIX existen aproximadamente? Aproximadamente 100.
- ¿Qué categorías de servicios ofrecen? Creación y terminación de procesos, manejo de archivos y directorios, entrada y salida.
- ¿POSIX especifica si una llamada es al sistema o de biblioteca? No, solo exige que esté disponible, no cómo implementarse.
- ¿Puede una función POSIX no invocar una llamada al sistema? Sí, si puede ejecutarse en espacio de usuario se prefiere por rendimiento.
- ¿Puede una llamada servir a múltiples funciones de biblioteca? Sí, especialmente si son variaciones menores.