On Sun, 15 Jul 2007 21:56:57 -0400 (EDT)
"Jared D. McNeill" <jmcneill@invisible.ca> wrote:

> Heyas folks --
> 
> I've begun work on a device class-based power management framework.
> The goals of this exercise are as follows:
> 
>   1. Having a centralized policy for managing device power policies.
> As each device class has different requirements, this framework
> manages those interactions in a common way.
>   2. Turn off devices when not in use, and waking them when required.
>   3. Eventually, nuke the powerhook_establish/powerhook_disestablish
>      framework in favour of this new power handler API for purposes of
>      global system sleep.
> 
> Points 1 and 2 are the focus of my current work. I have implemented
> input, audio, and display device class policies along with a sample
> power management handler for the wskbd(4) driver (input class),
> azalia(4) (audio class), and vesafb(4) (display class).
> 

I'm glad to see this; it will help a lot.  A few thoughts...

Disk drivers, at the least, need the ability to wait until many pending
commands are finished, I suspect.  Perhaps network devices do as well,
but packet loss at such a time isn't a problem.

A time delay should be added to some requests.  dhclient already has
problems with autonegotiation (especially 802.11 links, in my
experience, but also gigE) because of how frequently it does ifconfig
down/up cycles; this might make it worse.  Disk drives can require a
few seconds to spin up before they're ready; some component (I'm not
sure which) is going to need to be cognizant of that delay.

There probably needs to be some notion of topology, so that things like
USB hubs can be powered down at the right time.  We may also need a
user-level tool to check the power state of various pieces.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb