tipos - Llamada de sistema vs llamada de función
reglas de llamadas al sistema (10)
En realidad, la llamada al sistema no está relacionada con la llamada a la función. Lo único común de estos dos mecanismos es que ambos proporcionan servicios a la persona que llama.
Desde la vista de ejecución de hilos para ver la llamada al sistema:
Una llamada al sistema es una función para que el programa en modo de aplicación solicite servicios proporcionados por el sistema operativo subrayado. La llamada al sistema llevará el hilo en ejecución desde el modo de usuario al modo kernel, ejecutará la función del manejador de llamadas del sistema y luego regresará al modo de usuario.
Parámetros de Syscall:
El parámetro de una llamada al sistema es (syscall number, params ...). El significado y el formato de los parámetros dependen del número de syscall.
Desde la vista de la biblioteca syscall proporcionada al programa userland:
El programa de modo de usuario normalmente llama a la biblioteca de glibc para llamar a la llamada al sistema. Por ejemplo, la función open () en glibc:
- poner el número de llamada del sistema SYS_OPEN en el registro eax
- solicite una llamada al sistema llamando a una instrucción de interrupción de software o sys_enter
¿Cuál es la diferencia entre una llamada de sistema y una llamada de función? ¿Es fopen () una llamada de sistema o una llamada de función?
La llamada al sistema se ejecuta a nivel de kernet y no en el usuario spce porque requiere algún privilegio para acceder al hardware.
Por lo tanto, cuando se programa en el espacio de usuario y se realiza una llamada de función normal como fopen en lenguaje C, la libc generalmente envuelve esta función con un código de código específico donde se genera una interrupción para cambiar de espacio de usuario a espacio de kernel, luego en el espacio de kernel se requiere la llamada del sistema requerida La funcionalidad de la llamada de función a nivel de hardware se ejecutará en el espacio del kernel.
La pregunta ya tiene excelentes respuestas, pero creo que puedo agregar algo (un segmento de ostep que aún no está en otras respuestas)
A veces, la llamada al sistema y la llamada a la función tienen la misma firma, por ejemplo, open() :
llamada al sistema open()
--- ~/Documents » man open(2)
OPEN(2) Linux Programmer''s Manual OPEN(2)
int open(const char *pathname, int flags);
int open(const char *pathname, int flags, mode_t mode);
...
llamada open()
$ man open(3)
--- ~/Documents »
OPEN(3P) POSIX Programmer''s Manual OPEN(3P)
...
int open(const char *path, int oflag, ...);
...
Formulario de ostep
Puede preguntarse por qué una llamada a una llamada del sistema , como
open()oread(), se ve exactamente como una llamada a un procedimiento típico en C; es decir, si se parece a una llamada de procedimiento , ¿cómo sabe el sistema que es una llamada de sistema y hace todo lo correcto? La razón simple: es una llamada de procedimiento , pero oculta dentro de esa llamada de procedimiento está la famosa instrucción de captura . Más específicamente, cuando llama aopen()(por ejemplo), está ejecutando una llamada de procedimiento en la biblioteca de C. En este documento, ya sea paraopen()o para cualquiera de las otras llamadas al sistema provistas, la biblioteca usa una convención de llamadas acordada con el kernel para poner los argumentos a abrir en ubicaciones conocidas (por ejemplo, en la pila o en registros específicos). ), también coloca el número de llamada del sistema en una ubicación conocida (de nuevo, en la pila o en un registro ), y luego ejecuta la instrucción de captura mencionada anteriormente. El código en la biblioteca después de la captura desempaqueta los valores de retorno y devuelve el control al programa que emitió la llamada al sistema . Por lo tanto, las partes de la biblioteca de C que realizan llamadas al sistema se codifican a mano en el ensamblaje, ya que deben seguir cuidadosamente la convención para procesar los argumentos y devolver los valores correctamente, así como para ejecutar la instrucción de captura específica del hardware. Y ahora sabe por qué personalmente no tiene que escribir código de ensamblaje para atraparlo en un sistema operativo; alguien ya ha escrito esa asamblea para ti.
Si está utilizando Linux, puede supervisar las llamadas al sistema realizadas por una aplicación:
strace appname ...
Su salida puede darle una buena idea de lo que está sucediendo dentro de libc, y qué funciones son en realidad llamadas al sistema.
Solo para completar la imagen presentada por los demás, fopen se implementa comúnmente como un envoltorio alrededor de open , que también es una función accesible para el usuario. fopen es, en cierto sentido, un nivel más alto que open ya que la estructura de FILE* que retorna encapsula cosas para el usuario. Algunos usuarios utilizan open directamente para necesidades especiales. Por lo tanto, no sería correcto llamar a fopen una "llamada al sistema" de ninguna manera. Tampoco ejecuta las llamadas al sistema directamente , ya que open es también una función que puede ser ejecutada por el usuario.
Un punto de vista para agregar a esta discusión es que una llamada de función generalmente en el caso más optimista tiene una sobrecarga de unas pocas instrucciones de 8 bits (4-10 en promedio) en x86.
Una llamada al sistema tiene las siguientes propiedades.
- Ejecuta muchas más instrucciones, tiene que congelar un proceso en lugar de simplemente el estado de la pila.
- El tiempo involucrado es en su mayoría no determinista.
- A menudo es un lugar de programación, y el programador puede elegir reprogramar.
Por estas tres razones primitivas (probablemente hay más), uno debería reducir la cantidad de llamadas al sistema siempre que sea posible, por ejemplo, el software del sistema en red mantiene los manejadores de zócalos (y otras estructuras de datos internas específicas de la aplicación utilizadas por una conexión) para asignar nuevas Conexión, ¿por qué molestar al kernel?
Recuerde que el software está construido como una pirámide al revés. Las llamadas al sistema están en la base.
Una llamada del sistema es una llamada al código del kernel, que generalmente se realiza ejecutando una interrupción. La interrupción hace que el kernel tome el control y realice la acción solicitada, luego devuelve el control a la aplicación. Este cambio de modo es la razón por la que las llamadas del sistema son más lentas de ejecutar que una función equivalente de nivel de aplicación.
fopen es una función de la biblioteca de C que, internamente, realiza una o más llamadas al sistema. En general, como programador de C, rara vez necesita usar llamadas al sistema porque la biblioteca de C las envuelve por usted.
fopen es una llamada de función.
Una llamada al sistema interactúa con el sistema operativo subyacente, que administra los recursos. Sus órdenes de magnitud son más caras que una llamada de función, ya que se deben tomar muchos pasos para preservar el estado del proceso que realizó el syscall.
En los sistemas * nix, fopen wraps open, lo que hace que el sistema llame (open es la envoltura C para syscall). Lo mismo sucede con fread / read, fwrite / write, etc.
Here hay una buena descripción de las tareas ejecutadas por un syscall de Unix.
La llamada al sistema en realidad llama a una API ejecutada por el espacio del kernel. Con todos los costos asociados que esto supone (vea Wiki, o este enlace para más detalles)
Una llamada de función es una llamada a un fragmento de código en el espacio del usuario.
Sin embargo, tenga en cuenta que una llamada de función PUEDE ser una función que, en el proceso de su ejecución, realiza llamadas al sistema, siendo "fopen" uno de esos ejemplos. Entonces, si bien la llamada a fopen en sí misma es una llamada a una función, no significa que la llamada al sistema no suceda para manejar el IO real.
fopen es una llamada de función, pero a veces puede denominarse una llamada al sistema porque, en última instancia, es manejada por el "sistema" (OS). fopen está integrado en la biblioteca de tiempo de ejecución de C.