Some operating systems support the concepts of Plug and Play (PnP), Power Management and System Management for a plurality of different device drivers. Unfortunately, the complexity involved in implementing PnP and Power has caused thousands of device drivers to be written in a manner that may cause operating system problems (e.g., system crash). Beyond system failures, many designers of device drivers choose to simplify their drivers as much as possible, so that they do not have to complicate their designs with difficult programming problems, testing problems, and/or verification problems. This often leads to drivers which perform Power Management in the simplest way possible, which is merely to leave the corresponding device turned on, consuming fill power at all times. This consequently leads to laptop and tablet computers that consume more energy than they need to, thus causing shorter battery life than possible.
In one current operating system scenario, existing programming models do not always facilitate implementing PnP and Power management considerations in an efficient or robust manner. For example, a PnP “start” event may be modeled as an implicit power-up event, even though the power manager did not send it. Similarly, PnP “stop” and “remove” events are implicit power-down events. This implies that coordination and synchronization between PnP and Power events would then be performed inside every device driver, and not merely inside PnP or Power Managers.
In another example, power management in some models may be broken into two separate concepts, system power management and device power management. Thus, the operating system (or components associated therewith) decides when the system is awake or asleep, and the individual device drivers decide when the devices should be awake or asleep. In many ways, this is desired, since it implies that device power policy can be managed by software components that have the most device domain knowledge. In many other ways, it's frustrating for a device driver designer, since it forces the designer to track system power states, responding to them by putting the device into appropriate device power states. This tracking and coordination is complex and error-prone at best.
In order to save battery power, it should be theoretically possible to turn off devices that aren't currently being used. This goal is difficult to achieve with existing models, since the device driver has to track system concepts such as general idleness, time since the device was last asked to perform a task, and so forth. Turning unused devices off can certainly save power, however many devices need to remain powered on in order that software can be aware that a human has interacted with them. A good example is a floppy disk drive. It would be desirable if the floppy were turned off when it is not being used, since it is very rarely used in many situations. The operating system can certainly turn it on before it starts writing to the floppy or reading from it. The problem arises when a user puts a new floppy into the drive. Software should typically respond by changing any windows that currently show the contents of the floppy, and updating them with the list of newly inserted files. If a “disk-change notification” is not sent, then the device cannot be turned off.
The above floppy drive problem can be solved in a drivers framework by allowing each device to have a “wake signal” at the hardware level that can bring the device back into a working state. The problem is that almost all hardware in existence ties the wake signal into logic that controls the current power state, and the current power state is managed with a completely separate event. Thus, device drivers are forced to use two completely separate and unsynchronized events to manage a process that is essentially an interconnected and synchronized hardware subsystem. In view of the problems listed above and others, many machines such as laptop computers suffer from poor battery life.
USPTO Backgrounds
USPTO Backgrounds