Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Ver: Modo: Orden:
gestion de interrupciones | 9 comentarios (9 temáticos, editoriales, 0 ocultos)
En líneas generales... (none / 0) (#9)
por jorginius ("jorginius" en Google Mail) a las Tue May 10th, 2005 at 05:20:33 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Hago un remix y te contesto por aquí a los dos posts.

Supongo que una vez que accedo al hardware, debo hacer un enable_irq()?.

En principio sí, lo único que tiene que ser atómico es el acceso al hardware y a lo que compartan las interrupciones y el bottom half, si lo hay.

Luego cada dispositivo es un mundo y hay que calibrar lo que tiene que ir en el manejador y lo que puede ser ejecutado con las interrupciones activadas.

¿como se sabe a que proceso hay que darle los datos que, por ejemplo, se han recibido del dispositivo?

¿Quién y a qué proceso?, ¿el sistema operativo?, ¿a un proceso de usuario o a un hilo del sistema?. Hay mil formas. No es problema.

Solo tengo semaforos (y gracias). No tengo spinlocks ni ninguna otra primitiva de sincronizacion Un spinlock es, a fin de cuentas, un semáforo binario. Uno rápido, con espera activa preferentemente.

Si tienes semáforos lo tienes todo.

En la cola de interrupciones (supongo que una por linea de IRQ)

No tiene por qué. Depende del diseño, de donde reconozcas la interrupción, etc. Puedes guardar un identificador y que haya un dispatcher que esté recorriendo la cola y llamando al manejador adecuado según el id.

A veces resulta que es el hardware mismo el que encola las interrupciones.

Una "cola global" es bastante típica. Por ejemplo: al llegar una interrupción hardware, el top half, aparte de hablar con el hardware y pasar lo que le dé el dispositivo a un buffer, encola una tarea (el bottom half o manejador de segundo nivel). Luego el planificador se ocupará de ejececutar esas tareas ya con las interrupciones habilitadas.

Ah, una cosa que te aseguran todos los SO AFAIK es que, aunque los bottom half pueden ser interrumpidos, uno no puede estar ejecutándose más de una vez simultáneamente (las nuevas interrupciones que llegan por la misma línea se encolan pero no se procesan hasta que no se acaba con las antiguas).

tendras un aviso de que hubo una irq y que se debera comprobar en el bottom half antes de irse a dormir si la cola esta vacia, no?.

Bueno, la idea era un semáforo que lleve la cuenta de las interrupciones que quedan pendientes por procesar en la cola. El manejador lo incrementa y, si no hay más interrupciones, el bottom half se bloquea en el semáforo.

No sé, es un ejemplo: la idea es esa pero luego lo implementas como quieras. Este esquema tal cual no funciona si quieres más de un bottom half por interrupción pero se puede adaptar.

[ Padre ]


 

gestion de interrupciones | 9 comentarios (9 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:
Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda