> My understanding is in a driver: > - use "schedule()" when waiting for kernel services. > - use timers when waiting for the device. Hi Stephan, You got it all right except the fact that you cannot use a timer because timers execute in interrupt context, not process context. When your Process requests for a kernel service and your driver can't fulfill that service immediately due to lock contention or simply because it doesn't have the results immediately, or some other reason, it sleeps. Picture this, a process requests for a service but the driver can't do it immediately. Say you write some code in a timer and it gets called periodically and checks if it can do the work. But how does it (the timer code) know which process to do the work for? You have no direct way of accessing the process from the code you just wrote in a timer (for example you can directly access the process that requested for the service using the current macro but you can do so only in process context, not from your timer code) The "timer" you are referring to is already there and it periodically wakes your process - it is the scheduler's timer. Hope this brings you some more clarity, Thanks, -Joel -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
