I was going through the userspace input output drivers that eliminates the drawback of kernel crashing due to the inapproriate functioning of the driver code.
If kernel has scheduled a process1 and if the process1 is already running in the CPU, during the active process1 running, if a process2 from other devices requests for a service, then the priority to run the process2 becomes high [ through the generation of an interrupt]
Likewise, in user space drivers, the interrupt handler resides in the user mode and the detection and invocation of the interrupt happens in the kernel mode. Once an interrupt is handled during the device insertion, can there be multiple interrupts coming from the same device [other than insertion]. Guess read/write to the device may cause the interrupt again to be handled. But according to my understanding of the code i the read() of syscall will be made from the user mode ISR driver [CIF driver in this case] and the user mode interrupt handler will be put in a waitqueue by the uio_read() [in the uio.c ] until an kernel interrupt occurs. I could look through that the kernel interrupt uio_interrupt() occurs only during the device initialisation through the uio_register_device() call.
How does the kernel interrupt occurs for the same CIF device once again, so that it wakes up the sleeping interrupt handler and process the interrupt?
