linux - systemcall - proceso padre e hijo sistema operativo

Secuencia de flujo de llamadas al sistema Linux

Question

Tenía una pregunta sobre el funcionamiento profundo de Linux.

Digamos que un proceso de subprocesos múltiples se está ejecutando en la CPU. Tendremos un hilo que se está ejecutando en la CPU en tal caso. En una imagen más amplia tendremos la página correspondiente que pertenece al Proceso que se está cargando en la RAM para su ejecución.

Digamos que el hilo hace una llamada al sistema. No estoy nada claro sobre el funcionamiento después de esto. La interrupción generará una llamada. Una de mis preguntas es ¿quién responderá a esta llamada?

Digamos que el sistema tiene m: n subproceso de nivel de usuario a asignación de subprocesos de nivel de núcleo, supongo que el subproceso de nivel de kernel correspondiente responderá a esta llamada.

Entonces Kernel buscará la tabla de vectores de interrupción y obtendrá la rutina que necesita ser ejecutada. Mi siguiente pregunta es ¿qué pila se usará en la ejecución de la interrupción? ¿Será la pila del hilo Kernel o la pila del hilo del nivel de usuario? (Estoy asumiendo que será la pila del hilo Kernel).

Volviendo al flujo del programa, digamos que la operación está abriendo un archivo usando fopen . La siguiente pregunta que tengo es ¿cómo se llevará a cabo el salto del ISR a la llamada al sistema? ¿O nuestro ISR está asignado a una llamada al sistema?

También en una imagen más amplia cuando se está ejecutando Kernel Thread supongo que la "región OS" en la RAM se utilizará para albergar las páginas que están ejecutando la llamada al sistema.

Nuevamente mirándolo desde un ángulo diferente (Espero que sigas conmigo), finalmente estoy asumiendo que el Subproceso Kernel correspondiente está siendo manejado por el Programador de CPU donde en un cambio de contexto habría pasado desde el Subproceso de Nivel de Usuario al Subproceso de Nivel de Kernel correspondiente cuando se estaba respondiendo la llamada al sistema fopen .

He hecho muchas suposiciones y sería absolutamente fantástico si alguien pudiera despejar las dudas o al menos guiarme en la dirección correcta.

Answer 1

Nota: trabajo predominantemente con máquinas ARM, por lo que algunas de estas cosas podrían ser específicas de ARM. Además, intentaré simplificarlo tanto como pueda. Siéntase libre de corregir cualquier cosa que pueda estar mal o demasiado simplificada.

Digamos que el hilo hace una llamada al sistema. No estoy nada claro sobre el funcionamiento después de esto. La interrupción generará una llamada. Una de mis preguntas es ¿quién responderá a esta llamada?

Por lo general, el procesador comenzará a ejecutarse en una ubicación predeterminada en modo kernel. El kernel guardará el estado del proceso actual y observará los registros del espacio de usuario para determinar qué llamada al sistema se solicitó y enviarla al controlador de llamadas al sistema correcto.

Entonces Kernel buscará la tabla de vectores de interrupción y obtendrá la rutina que necesita ser ejecutada. Mi siguiente pregunta es ¿qué pila se usará en la ejecución de la interrupción? ¿Será la pila del hilo Kernel o la pila del hilo del nivel de usuario? (Estoy asumiendo que será la pila del hilo Kernel).

Estoy bastante seguro de que cambiará a una pila de kernel. Habría algunos problemas de seguridad bastante severos con filtraciones de información si usaran la pila de espacio de usuario.

Volviendo al flujo del programa, digamos que la operación está abriendo un archivo usando fopen. La siguiente pregunta que tengo es ¿cómo se llevará a cabo el salto del ISR a la llamada al sistema? ¿O nuestro ISR está asignado a una llamada al sistema?

fopen() es en realidad una función libc y no una llamada al sistema en sí misma. Sin embargo, puede (y en la mayoría de los casos lo hará) llamar a open() syscall en su implementación.

Entonces, el proceso (más o menos) es:

1. El espacio de usuario llama a fopen()
2. fopen realiza una llamada al sistema para open()
3. Esto desencadena algún tipo de excepción o interrupción. En respuesta, el procesador cambia a un modo más privilegiado y comienza a ejecutarse en alguna ubicación preestablecida en el kernel.
4. Kernel determina qué tipo de interrupción y excepción es y lo maneja de forma adecuada. En nuestro caso, será una llamada al sistema.
5. Kernel determina qué llamada al sistema se solicita al leer los registros de espacio de usuario y extrae los argumentos y los pasa al controlador apropiado.
6. Handler se ejecuta.
7. Kernel pone cualquier código de retorno en los registros de espacio de usuario.
8. Kernel transfiere la ejecución a donde ocurrió la excepción.

También en una imagen más amplia cuando se está ejecutando Kernel Thread supongo que la "región OS" en la RAM se utilizará para albergar las páginas que están ejecutando la llamada al sistema.

Las páginas no ejecutan nada :) Generalmente, en Linux, cualquier dirección mapeada arriba de 0xC0000000 pertenece al kernel.

Nuevamente mirándolo desde un ángulo diferente (Espero que sigas conmigo), finalmente estoy asumiendo que el Subproceso Kernel correspondiente está siendo manejado por el Programador de CPU donde en un cambio de contexto habría pasado desde el Subproceso de Nivel de Usuario al Subproceso de Nivel de Kernel correspondiente cuando se estaba respondiendo la llamada al sistema fopen.

Con un kernel preferente, los hilos efectivamente no son discriminados. Según tengo entendido, un nuevo hilo no se crea con el propósito de dar servicio a una llamada al sistema; simplemente se ejecuta en el mismo hilo desde el que se solicitó la llamada al sistema, excepto en el modo kernel.

Eso significa que un subproceso que se encuentra en el modo kernel y que atiende una llamada al sistema se puede programar de la misma manera que cualquier otro subproceso. Por lo tanto, aquí es donde escuchas acerca del ''contexto del espacio de usuario'' cuando se desarrolla para el kernel. Significa que se está ejecutando en modo kernel en un subproceso de modo de usuario.

Es un poco difícil explicar esto, así que espero haberlo hecho bien.