linux - tag - musicbrainz picard

Señala e interrumpe una comparación. (3)

Basado en varias referencias, mi definición subjetiva de señales en Linux es "Los desencadenantes que se usan para notificar a los procesos sobre la ocurrencia de un evento específico. Aquí, el evento puede referirse a una excepción de software. Además, las señales también se pueden usar para mecanismos de IPC. " Las preguntas que tengo son

Supongo que solo las excepciones (interrupciones de software) se notifican a través de señales. ¿Qué pasa con el caso de interrupciones de hardware?
¿Cuáles son las diversas fuentes de la señal? Para mí, parece que el kernel siempre es la fuente de una señal (excepto cuando se usa para IPC)
¿Diferencia entre el manejador de señal y el ISR ?.
¿Diferencia entre el bloqueo de la señal y la máscara de interrupción?

Supongo que solo las excepciones (interrupciones de software) se notifican a través de señales. ¿Qué pasa con el caso de interrupciones de hardware?

Dónde empezar ? Hay muchos casos diferentes. Tenga en cuenta que las interrupciones son el hardware que llama a la CPU. Las interrupciones consisten esencialmente en "hardware necesita atención" y un número entre 0 y 255. Las señales son similares pero tienen 2 parámetros: identificación del proceso de destino y una int (32 bits o 64 bits, según el arco). Las interrupciones de hardware siempre se manejan en el espacio del kernel, mientras que las señales son solo cosas del espacio del usuario. El kernel usa interrupciones de hardware por varias razones.

Un ejemplo de una interrupción de hardware que no tiene nada que ver con las señales es el subsistema VM. Sabe que en los sistemas operativos modernos puede asignar más memoria de la que realmente existe en el sistema. Entonces, cómo funciona esto ? Bueno, funciona explotando interrupciones de hardware. Cuando asignas memoria, el kernel toma nota de ello, pero en realidad no hace nada. Luego, cuando intenta acceder a la memoria asignada, la CPU se quejará "pero esta memoria no existe", lo que generará una interrupción de hardware. El núcleo irá a revisar sus notas, encontrará que efectivamente solicitó esa memoria, borre un poco de la memoria que tiene libre y pídale a la CPU que "asigne" esa memoria en la ubicación esperada. Después de lo cual el kernel reanuda su programa en el punto justo antes de que ocurriera la interrupción del hardware y esta vez el proceso encontrará la memoria perfecta.

La multitarea también se implementa mediante la explotación de una interrupción de hardware. Todos los conductores generalmente trabajan interpretando interrupciones.

Las señales se utilizan para comunicarse entre procesos. Algo muy "señal-y" sería el comportamiento común de los demonios de Linux para volver a cargar su configuración en SIGHUP, amado y odiado por los administradores de sistemas en todos los lugares. Cuando modifica, digamos, una configuración de apache, el proceso no comienza automáticamente usando la nueva configuración. Puede terminar y reiniciar el proceso, pero eso significa que 4-5 segundos su servidor http estará fuera del aire. Así que en lugar de eso, podrías "killall -HUP apache". Esto llamará a una subrutina en el proceso de apache, lo que hará que vuelva a leer su archivo de configuración.

El proceso de suspensión se implementa a través de señales (ctrl-z), proceso de interrupción (ctrl-c), proceso de salida (ctrl-), desconexiones de terminal (sighup), ... se puede encontrar una lista más completa aquí: http://en.wikipedia.org/wiki/Unix_signal .

Una conclusión podría ser que son similares, pero operan a un nivel diferente: las interrupciones de hardware son, bueno, el hardware que clama por atención, y el software de nivel más bajo obliga. En general, el kernel maneja todo el hardware, y los procesos de información se realizan de forma algo independiente de las interrupciones del hardware. Para una serie de señales se proporciona manejo predeterminado (por ejemplo, ctrl-z, ctrl-c, ...), para otros, la implementación depende mucho de la aplicación (por ejemplo, SIGHUP).

Cuando se trata de señales, estas son solo aplicaciones definidas por software. Hacen lo que usted quiera que hagan, y Linux viene con métodos convenientes para llamar a estas subrutinas. En algunos casos, el núcleo puede llamar a una rutina de señal (por ejemplo, SIGSEGV, SIGCHILD, ...), pero casi nunca involucra hardware. Solo son una forma conveniente de activar una rutina específica en una aplicación.

Solía haber un caso especial: la interrupción "OS", en DOS 21h. Esto ya no se usa (aunque todavía funciona), pero la idea es esta. Un programa puede activar una interrupción específica para pedirle al núcleo que realice acciones específicas. Las acciones son los syscalls (abrir un archivo, cerrar un socket, lo que sea). Como dije, interesante, pero ya no se usa realmente.

¿Cuáles son las diversas fuentes de la señal? Para mí, parece que el kernel siempre es la fuente de una señal (excepto cuando se usa para IPC)

Una señal proviene del proceso en sí (SIGABRT), del kernel (SIGSEGV, ...) o de otros procesos, como el shell por ejemplo (ctrl-z, ctrl-c, ctrl- /, ...) o de matar Pero pueden provenir de cualquier otro programa a través de la función kill libc:

#include <sys/types.h> #include <signal.h> int kill(pid_t pid, int sig);

¿Diferencia entre el manejador de señal y el ISR ?.

La principal diferencia es que los ISR viven en el espacio del kernel y deben tener en cuenta que toda la computadora está congelada durante su ejecución. Esto significa que pueden haber interrumpido cualquier proceso, y cualquier cosa en el kernel. También "paran el mundo". Mientras se maneja una interrupción, nada más sucederá. Entonces, si un manejador de interrupciones espera algo, la máquina se congela. Si un manejador de interrupciones entra en un bucle, su única opción es reiniciar la máquina.

Los ISR son realmente difíciles de hacer bien. Hay mucha teoría sobre ellos, en linux tienen la mitad superior y la mitad inferior, con todo tipo de manejo de prioridad, asignación de memoria especial, ... y es un campo minado. Un paso en la dirección equivocada en un ISR matará a la máquina. Un error en un ISR causará dataloss, tal vez incluso un fallo total del hardware. De hecho, hablando por experiencia, el simple hecho de despertar sospechas de que podría estar planeando hacer algo mal en un ISR da como resultado inmediatamente un comportamiento de la máquina completamente impredecible.

No se pueden usar las instalaciones del núcleo en ISRs. Abriendo un archivo, olvídalo. Asignando memoria, olvídalo. Al llamar a cualquier otra parte del kernel, olvídelo (con algunas excepciones, pero solo unas pocas). La lista continua.

Las señales son solo funciones en procesos específicos que se llaman. Una señal puede bloquear (por ejemplo, ctrl-z) y esto impedirá que el proceso avance, pero por ejemplo, su sesión de shell seguirá respondiendo. El proceso debe tener en cuenta que cualquier parte del programa puede haber sido interrumpida, por supuesto, pero sigue siendo un espacio normal para el usuario. Puede bloquear, puede hacer un bucle, puede abrir archivos, asignar memoria, ... lo que quiera.

¿Diferencia entre el bloqueo de la señal y la máscara de interrupción?

Son bastante similares. Excepto que el bloqueo de la señal se realiza por proceso. En ambos casos, hay señales que no se pueden bloquear y hay una NMI (interrupción no enmascarable) (ambas indican errores graves).

Al final, las señales y las interrupciones envían un número, ya sea al núcleo o a un proceso específico. El bloqueo de la señal y el enmascaramiento de interrupción solo significa decirle al sistema que ignore números específicos.

Una diferencia es que la máscara de interrupción se implementa en hardware.

Las interrupciones se pueden ver como un medio de comunicación entre la CPU y el núcleo del sistema operativo. Las señales pueden verse como un medio de comunicación entre el núcleo del sistema operativo y los procesos del sistema operativo.

Las interrupciones pueden ser iniciadas por la CPU (excepciones, por ejemplo: división por cero, error de página), dispositivos (interrupciones de hardware, por ejemplo: entrada disponible), o por una instrucción de la CPU (trampas, por ejemplo: syscalls, puntos de interrupción). Finalmente, son administrados por la CPU, que "interrumpe" la tarea actual e invoca un controlador ISR / interrupt provisto por el kernel del SO.

Las señales pueden ser iniciadas por el núcleo del sistema operativo (por ejemplo: SIGFPE, SIGSEGV, SIGIO), o por un proceso (kill ()). Eventualmente, son administrados por el núcleo del sistema operativo, que los entrega al subproceso / proceso objetivo, invocando una acción genérica (ignorar, terminar, terminar y volcar el núcleo) o un controlador de señales proporcionado por el proceso.

Las señales e interrupciones se comportan de manera bastante similar. La diferencia es que las señales pasan a un proceso (que vive en un entorno virtual), mientras que las excepciones se aplican a todo el sistema.

Ciertos fallos son marcados por la CPU como una excepción, y luego asignados a una señal que es entregada al proceso por el kernel. El núcleo puede optar por ocultar cualquier excepción del proceso (por ejemplo, los accesos a la memoria no asignada se arreglan silenciosamente mediante la paginación).

Las interrupciones de hardware son simplemente un tipo de excepción, que el núcleo puede elegir asignar a una señal (por ejemplo, si usa la alarm(2) ).

El kernel genera señales en respuesta a diversos eventos, entre ellos excepciones, finalización de E / S, solicitudes explícitas de espacio de usuario, ...

Los manejadores de señales se comportan de manera similar a los ISR: pueden invocarse en cualquier momento, por lo que no pueden hacer suposiciones sobre el estado del programa, al igual que los ISR, y las señales de bloqueo se comportan de la misma manera dentro del espacio de direcciones virtuales como lo hacen las interrupciones de máscara. En la máquina física.