Re: Schedule() call in driver context.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Joel,


> > 1. What event awakes the process? Has the driver any way to control it?

> 
> The kernel code executing on behalf of the process is usually waiting
> for some resource to become available, we sleep because we can't
> return from the middle and have to wait till we get the resource. For
> example, consider a write operation being done on a page belonging to
> a file -by 2 processes. They both can't write to the same page at the
> same time, so what happens is the kernel locks the first page on
> behalf of say process 1 and copies data into it, updates its flags and
> whatever. Now while this is going on, when the other process tries to
> lock the same page, it will be put to sleep (and added to a wait
> queue) till the lock is available. You usually don't want to return
> till you have this resource available. So during this kind of lock,
> the process is put on a wait queue and when the lock is free, any
> processes on this queue are woken up. There is usually some sort of a
> wait queue for each event/resource and on completion of a certain
> event, processes from these lists are woken up.

I'm little confused here (please correct me if I'm wrong) :

AFAIK when in driver context you wait only for device events. I mean, even
you have an interrupt handler or you poll a device register. The other, 
common system resources as memory, pages, locks, timers, ... are taken 
care by the kernel without any action of your side. If your driver tries to access 
a page which is not available at a time the kernel would put your driver/user-
process at sleep until the resource becomes available. No need for  the 
driver to do any preventive action. Unless, as pointed in previous answers,
the driver is in an intended endless loop and wants to let the others to get 
some CPU.

For this purpose(driver/device) I do not see any way to specify some wait-condition 
when calling "schedule()". Maybe I miss the point.. From what I see in the actual
driver code I feel like the driver, if in lengthy operations has to check some "flag" 
and if set to give up the CPU until the kernel calls it again.


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


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux