Reputation: 571
This might well be a duplicate, but I haven't found a Q&A or example quite down to my level...
I'm trying to add interrupt handling to a simple Linux driver (which currently just implements mmap
for some hardware registers). I want to keep as much functionality as possible in user-space for now, for flexibility of development. So I just want the kernel driver to handle (and clear) the IRQ, and implement either a poll
or read
file operation so user code can wait for it efficiently.
I don't plan to poll or read from more than one thread, so I don't care if it's single-wakeup or broadcast. I do care about cases where an interrupt happens before poll starts: this should cause the next poll (or read) to return immediately.
My question is about the synchronization between the ISR and the file operation. What kind of synchronization object(s) or pattern is appropriate? The examples I've seen mostly involve a "wait queue", which might produce a race condition if the interrupt occurs just after checking for it but before the poll gets onto the queue.
(Coming from an RTOS background, what I feel I want is a binary semaphore that the ISR can raise, and the poll (or read) operation can pend. I'm not sure if that's available in Linux?)
Thanks
Upvotes: 0
Views: 582
Reputation: 571
For completeness, having pored through LDD3, I'll sketch an answer to my own question.
As Ian Abbott suggested above. It's for just this kind of scenario.
I'd misunderstood the function of poll_wait()
which doesn't actually wait, but merely registers the poll with the queue in some magical way. It is safe (and normal) to call it with a lock held. So there is no race condition.
A well-behaved driver would implement both poll
and read
.
Aside: LDD3 is very old. It pre-dates Platform and DevRes and probably many other things a driver writer should know about. Is there a modern equivalent (not necessarily free)?
Upvotes: 1