In the last article, we discussed the usage of wait queues in Linux kernel. We saw the variants of wait_event(). Just for completeness, we will discuss how the wait queues are implemented internally. First step is the creation and initialization of wait queue entry. This is done as below:
DEFINE_WAIT(wait_entry);
Next step is to add the wait queue entry to the queue and set the process state. Both of these things are being done by a single function declared below:
prepare_to_wait(wait_queue_head_t *wq_head, wait_queue_t *wq, int state);
After this, we schedule out the process by invoking the schedule() API. Once we are done with waiting, next step is to clean up with the API below:
finish_wait(wait_queue_head_t *wq_head, wait_queue_t *wq);
All the above are available from:
#include <linux/wait.h>
One more point worth noting is that the condition has to be tested manually as was done in our earlier article.
The author used to work at Intel, Bangalore. The author is a Linux enthusiast and is interested in Linux porting, Linux Kernel Internal & Linux device drivers. He shares his learnings on Linux & embedded systems through his workshops & trainings. Learn more about his experiments at http://sysplay.in.
Pingback: Waiting / Blocking in Linux Driver Part – 3 | Playing with Systems
Nice article. My question is, shall we use this concept in character drivers(i2c/spi/uart).
Like say, an i2c driver reading data from device — shall i use this concept either wait/blocking
Not like wait in read function call and wake-up in the write function call.
Or
existing character drivers(i2c/spi/uart) are already blocking/wait device drivers.
Could you please help in understanding this concept.
Frankly speaking, this is a generic concept. It can be used anywhere, where it suits the best. Moreover, if I understand, the one shown above is just the framework, which is used internally by many others. The already blocking drivers may be ultimately using this internally.