Messages in this thread | | | Date | Wed, 28 Jul 1999 16:17:35 -0700 (PDT) | From | Linux Lists <> | Subject | Re: Handling interrupts from userspace |
| |
On Wed, 28 Jul 1999, Mark Hahn wrote: > > > Or (if possible) register the interrupt _from userspace_ and handle it > > directly. Is it possible ?!?! > > no, it's CERTAINLY not possible. interrupt handlers are extremely > special: Linux is a real OS, unlike DOS, where it was trivial to > handle interrupts yourself. consider, for instance, what happens if > your (hypothetical) user-level interrupt handler happens to be paged out.
Yeah, I understand. Actually, my development OS options are Linux and DOS (where I know I could just handle interrupts from userspace, because everything is userspace :). Guess which one I chose ... ;)
> > > normally, a user-level process > > > would just do a blocking read or ioctl, and the driver would sleep > > > the process until an interrupt comes in. > > > > The problem with that is that you're assuming there is already a driver > > for this specific device. I'm trying to write a HW test application that > > no, I'm making no such assumption. I'm stating that this could be done > with a new driver that was completely generic: you'd tell it to register > to handle a particular interrupt, then make some blocking call like > read or ioctl. the driver simply catches the interrupt, and wakes you up. > this is extremely simple, probably ~20 LOC. what's tricky is figuring out > how to do it usefully, handling things like interrupt masking/ack, etc.
Yes. How to clear the interrupt is a especially interesting one, because:
- each device has its own way of clearing it (how would you define the driver interface so that the application is able to tell, from userspace, how to clear the interrupt, and it's general enough to work with _any_ device??). - you would have to clear it _before_ you actually service it, otherwise you'll be stuck on the driver intr. handler and, thus, it'll be impossible to service it from userspace. But since you haven't serviced it, the interrupt would probably happen again, and then ... :)
> > does _not_ depend on a specific driver to work, an application that can > > access the specific HW directly and test it. I already know how to access > > MMIO, the PCI bus and such, but I don't know how to handle interrupts from > > userspace. > > > > Suggestions ?!?! > > a dummy interrupt driver.
Let's say we have this driver. How should the application and the driver interface ?? You've mentioned a blocking call. Could you give an example of that for this particular (hypothetic) case ?? I've also heard of using a task queue for that. Do you know anything about how to use it ?!?!
Thanks much for your comments so far.
Regards, Ivan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |