Safely suspending an IDE system

The 2.6 kernel will feature much improved power management, thanks to the device model, improved ACPI support, and a fair amount of effort in general to get power management right. One nagging problem remains, however, in the IDE subsystem. An IDE suspend or resume operation must be carefully serialized with any other operations happening within the same "hwgroup," where a hwgroup is a set of IDE devices that can only be accessed one at a time. Simply shutting down a drive when the kernel asks runs the risk of corrupting in-progress operations and generally making a mess of things.

Benjamin Herrenschmidt has now worked up a patch which deals with this problem, and, incidentally, shows off one of the design features of the 2.5 block I/O subsystem. The key to the solution is to realize that the IDE subsystem already has a mechanism which carefully serializes accesses to hwgroups: the block I/O request queue. If suspend and resume requests are put onto the request queue, the IDE subsystem will find (and act on) them at just the right time.

When one thinks of the I/O request queue, what usually comes to mind is commands to move data blocks to and from a drive. But, as covered in the LWN Driver Porting series, the newly redesigned block subsystem includes the ability to put other kinds of commands into request queues. This mechanism is used, for example, to queue packet-mode commands or explicit taskfile operations. But it can also be exploited to serialize power management commands.

So, all that was required is a new REQ_POWER_MANAGEMENT request type. The desired power management state is stored in the special field of the request structure, which is added to the target drive's request queue. When the hwgroup has finished up any other outstanding operations it may have going, it will see the power management request and deal with it at the right time. Problem solved.

---

(Log in to post comments)