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:
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:
One more point worth noting is that the condition has to be tested manually as was done in our earlier article.
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.
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.