Day85 - poll() Internals¶
Objective¶
Understand how Linux poll() integrates with wait queues to implement event-driven I/O.
This lab builds a simplified poll subsystem step by step and demonstrates how a userspace poll() operation interacts with a driver's poll callback.
Learning Objectives¶
After completing this lab, you should understand:
- The purpose of
poll() - How
poll_wait()works - The role of
poll_table - Driver
pollcallback flow - Event masks (
POLLIN) - Relationship between
polland wait queues - Blocking event-driven I/O
Lab1 - Poll Table Registration¶
Objective¶
Build a simplified poll_table.
Implement:
poll_tablepoll_table_entrypoll_wait()
Verify that a poll operation records all monitored wait queues.
Expected Flow¶
Expected Result¶
- Three wait queues are registered.
- Dump shows every registered wait queue.
- Destroy correctly releases all entries.
Lab2 - Driver poll Callback¶
Objective¶
Implement a simplified driver poll callback.
Driver Flow¶
Validation¶
Case 1
Case 2
Lab3 - Userspace poll()¶
Objective¶
Simulate a simplified userspace poll().
Flow¶
Validation¶
When no data is available:
When data is available:
Lab4 - Blocking poll¶
Objective¶
Combine poll(), wait queues and wakeup.
Poll Thread¶
Producer Thread¶
Expected Output¶
Summary¶
This lab demonstrates the complete event-driven I/O flow:
Userspace poll()
↓
Driver poll()
↓
poll_wait()
↓
wait queue
↓
sleep
↓
wake_up()
↓
Driver poll()
↓
POLLIN
↓
read()
The most important takeaway is that:
poll_wait()only registers a wait queue.- It never blocks.
- The driver determines readiness by returning an event mask.
read()consumes the data afterpoll()reports that data is available.