Implementazione della corretta sincronizzazione tra moduli nel kernel Linux

Question

Sto implementando un driver di bus seriale personalizzato per una determinata scheda Linux basata su ARM (in realtà un driver UART personalizzato). Questo driver abilita la comunicazione con un determinato MCU all'altro capo del bus tramite un protocollo personalizzato. Il driver non (e in realtà non deve) esporre alcuna delle sue funzioni allo spazio utente, né è possibile implementarlo nello spazio utente (quindi, la necessità del driver personalizzato invece di utilizzare il sottosistema TTY originale).

Il driver attuerà il protocollo di comunicazione e UART letture/scritture, e deve esportare un insieme di funzioni di livello superiore ai propri utenti per consentire loro di comunicare con la MCU (ad esempio read_register(), drive_gpios(), tutta questa roba) . Ci sarà un solo utente di questo modulo.

Il modulo di chiamata dovrà attendere il completamento delle operazioni (il già citato read_register() e altri). Attualmente sto prendendo in considerazione l'utilizzo di semafori: il modulo utente chiamerà la funzione del mio autista, che avvierà i trasferimenti e attenderà un semaforo; il gestore IRQ del mio autista invierà richieste all'MCU e leggerà le risposte e, una volta terminato, postare al semaforo, risvegliando il modulo di chiamata. Ma non ho molta familiarità con la programmazione del kernel, e sono sconcertato dalla moltitudine di possibili implementazioni alternative (tasklet? Wait queues?).

La domanda è: il mio approccio basato sul semaforo è OK, o troppo ingenuo? Quali sono le possibili alternative? Ci sono delle insidie ​​che potrei mancare?

Answer 1

Tradizionalmente IRQ manipolazione in Linux è fatto in due parti:

1. cosiddetta "metà superiore" è effettivo di lavoro in un contesto IRQ (IRQ handler stesso). Questa parte deve uscire il più velocemente possibile. Quindi controlla fondamentalmente l'origine di interrupt e quindi avvia la metà inferiore.

2. "metà inferiore". Può essere implementato come coda di lavoro. È dove il lavoro reale è fatto. Si corre in un contesto normale, in modo che possa utilizzare le funzioni di blocco, ecc

Se solo si desidera attendere IRQ nel thread di lavoro, meglio usare oggetto speciale chiamato completion. È creato esattamente per questo compito.