Hi Greg,
> driver context? Not really a kernel term to my knowledge. I'll
> assume you mean in a driver directly associated with a user space
> call. ie. Not in interrupt mode
Sorry for the formulation. And yes I meant exactly what you suggesting.
> It is not at all uncommon to have access to those restricted via a
> semaphore or mutex. If you attempt to get a semaphore or mutex and it
> fails the underlying call may very well call schedule for you.
...
> If your driver can't ignore the hardware for a relatively long period
> of time then "schedule" may not be the call for you. But the general
> concept is to get all the high-speed priority work done in the
> interrupt driver. So even if it does take a few real seconds for the
> scheduler to re-schedule your task (and associated driver) it is not a
> big deal.
I think I start to see the rationale behind the use of "schedule()" call in
drivers. I need only your confirmation my thinking is correct.
A driver deals with two entities to fulfill user requests. One is the external
device and the other is the kernel which provides service/resource
support to driver. When the driver gets a negative answer to one of its
kernel requests it has two choices. To return immediately an error code
to the user or to wait a little and re-iterate the kernel call in the hope the
resource got freed. In this case it will call "schedule()".
Ex:
counter = 0 ;
while ( 0 == ( p = kmalloc ( size, GFP_USER )))
{
counter++ ;
if ( MAXCOUNT < counter ) return -ENOMEM ;
schedule () ;
}
do-the-remainder-of-the-work() ;
return 0 ;
My understanding is in a driver:
- use "schedule()" when waiting for kernel services.
- use timers when waiting for the device.
Am I right?
This is active learning!
Thanks, all the folks who spent time to enlighten me,
Stephan.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to [email protected]
Please read the FAQ at http://kernelnewbies.org/FAQ
