2012-04-02 9 views
7

Estoy implementando un controlador de bus serie personalizado para una cierta placa Linux basada en ARM (en realidad, un controlador UART personalizado). Este controlador debe permitir la comunicación con una cierta MCU en el otro extremo del bus a través de un protocolo personalizado. El controlador no (y de hecho no debe) expone ninguna de sus funciones al espacio de usuario, ni es posible implementarlo en el espacio de usuario en absoluto (de ahí la necesidad del controlador personalizado en lugar de usar el subsistema TTY común).Implementación de la sincronización correcta entre módulos en el kernel de Linux

El conductor va a implementar el protocolo de comunicación y UART lecturas/escrituras, y tiene que exportar un conjunto de funciones de nivel superior a sus usuarios para que puedan comunicarse con el MCU (por ejemplo read_register(), drive_gpios(), todas estas cosas) . Solo habrá un usuario de este módulo.

El módulo llamante tendrá que esperar la finalización de las operaciones (las read_register() antes mencionadas y otras). Actualmente estoy considerando usar semáforos: el módulo de usuario llamará a la función de mi controlador, que iniciará las transferencias y esperará en un semáforo; el controlador de IRQ de mi controlador enviará solicitudes a la MCU y leerá las respuestas, y, cuando termine, se publicará en el semáforo, lo que activará el módulo de llamadas. Pero no estoy muy familiarizado con la programación del kernel, y estoy desconcertado por la multitud de posibles implementaciones alternativas (¿tasklets? ¿Espera colas?).

La pregunta es: ¿está mi enfoque basado en semáforos bien o demasiado ingenuo? ¿Cuáles son las alternativas posibles? ¿Hay algún error que pueda estar perdiendo?

+3

Los semáforos deben hacer el trabajo por lo que entiendo, para comprender mejor las funciones internas de linux, consulte el libro "linex kernel development 3rd edition" que está disponible como pdf gratuito y está actualizado (kernel .39, creo). Ese libro no es realmente profundo, pero explica los principios básicos y muestra las opciones. Diviértete pirateando. – AoeAoe

+0

¡Un buen libro, gracias! Si alguien más está interesado, también sugiero obtener Linux Drivers Development y Linux Kernel Module Development (ambos están disponibles en línea gratis) –

Respuesta

5

Tradicionalmente IRQ en el manejo de Linux se hace en dos partes:

  1. Los llamados "mitad superior" es trabajo real en el contexto de IRQ (IRQ manejador de sí mismo). Esta parte debe salir lo más rápido posible. Por lo tanto, básicamente verifica la fuente de interrupción y luego comienza la mitad inferior.

  2. "Mitad inferior". Se puede implementar como cola de trabajos. Es donde se realiza el trabajo real. Se ejecuta en contexto normal, por lo que puede utilizar las funciones de bloqueo, etc.

Si sólo desea esperar a IRQ en su subproceso de trabajo, mejor usar objeto especial llamado completion. Está creado exactamente para esta tarea.

Cuestiones relacionadas