Conceptual
Login

Unbinding and Unloading a Driver Without Leaking Anything

A driver has to survive its device being taken away and itself being removed, in either order, without leaving a mapped region, a live interrupt handler or a freed buffer the hardware still believes it owns. You test this by detaching the driver from the device through the file system that controls binding, reattaching it, and unloading the module, watching that each resource is released in the right order and nothing complains. After it you can tell the difference between a driver that merely worked once and one that can be removed safely, which is the check a kernel reviewer applies first.

Questions this Concept answers

  • Why are the driver's resources tied to the bound device rather than to the module?