Day16 - IOCTL and Control Plane¶
What I Did¶
- Designed ioctl interface for mygpio driver
- Implemented:
- SET_DEBOUNCE
- GET_STATUS
- CLR_EVENTS
- Added control plane separate from data plane
- Implemented proper locking (mutex + spinlock)
- Verified functionality using user-space test programs
Key Learnings¶
1. IOCTL is command-based¶
Each command should have:
- its own structure
- clear responsibility
Avoid message-style design.
2. ABI is critical¶
IOCTL interface is not just code:
- it is a contract between user and kernel
- structure layout must remain stable
3. copy_to/from_user is mandatory¶
Never access user pointer directly.
4. Control Plane vs Data Plane¶
- Data plane → read/poll/event queue
- Control plane → ioctl
This separation makes driver design cleaner.
5. Locking Design¶
- spinlock → fast path / ISR / queue
- mutex → configuration / ioctl
6. Snapshot Design Trade-off¶
GET_STATUS is not fully atomic:
- acceptable in most drivers
- simplifies implementation
7. Debug Strategy¶
- dev_dbg → frequent operations
- dev_info → configuration changes
Challenges¶
- Understanding ioctl design vs message system
- Deciding whether to use union
- Handling locking between ISR and ioctl
- Designing clean interface structure
What I Improved¶
- Removed union-based ioctl argument
- Adopted command-per-struct design
- Separated locks for different data types
- Added validation and error handling
Result¶
The driver now supports:
- event-driven data flow
- configurable runtime behavior
- status query interface
This is a complete mini driver architecture.
Next Step¶
Possible directions:
- sysfs interface
- event timestamp support
- epoll improvement
- apply design to NFC driver