Hi Joel, > because timers execute in interrupt context, not process context. What do you mean exactly? My understanding is the kernel uses interrupts to count the time and to trigger timer routines - but these routine are executed in the context they were registered. A timer created by a process executes in process context. A driver registered timer executes in kernel context (not interrupt). Am I wrong? Now, regarding the device handling (previous mail) - here is what I had in my mind: Usually, in a simple character driver during the initialization you register with the kernel an interrupt handler which will handle the device events. This is done at boot time when the driver is loaded. The interrupt handler has no link to any user space processes. It sits there and just eats device interrupts guaranteeing the device data/control/status registers are handled properly. If there is some data to be read from the device it stores it in a circular buffer. The user side of the driver is handled in the open/close, read/write/ioctl, map/unmap, select/poll routines. Now, as Greg aforementioned there are devices which do not provide interrupts. In this case I think you have to replace the interrupt handler with a poll function which is triggered by a periodic timer registered in kernel context during the driver initialization. There is no interrupt at all. The driver looks identical with the previous with the exception of the interrupt/poll handler. I was thinking at this case when I said you use timers to wait for the device events. In fact is you use timers to poll for device events. And, as I just learned you use "schedule()" to wait for kernel resources. Hope you agree with my approach. Cheers, Stephan. -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
