On Tue, Feb 23, 2010 at 1:16 PM, StephanT <stman937-linewbie@xxxxxxxxx> wrote: > 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. > Stephen, You're missing a tier of complexity and I'm afraid I don't know the details myself as well as I should. Assume a userspace app writes data aimed at a file via write(): Kernel context is entered with the process/task structures set to identify the userspace app. The filesystem code does some magic and sends data to the block layer which can queue up a huge amount of data (think 100's of MB at times). Kernel returns control to userspace leaving the data sitting in block layer buffers. Now the data has to move from the block layer down into the HDD device drivers. I don't think this is occurring within the kernel with the process / task structures set to the original userspace app. Nor is it happening in interrupt context. Instead there is an intermediary context that I don't think you've taken into account. I believe timers are also invoked in this intermediary context. ie. When a timer invokes a function you can't trust the process / task structures to relate to your original userspace app. I hope I'm not confusing you, but it's been a while since I've had to have a discussion about this topic. Greg -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
