[linux-pm] PM:Different idea for callbacks, smoother evolution

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi!

First, I probably should explain my 3-letter post... See its headers
(user-agent and local time sent). Mail does not have
"sent-physical-location" but it would be "in the middle of
nowhere". (Well, local time would be "in the middle of the night", and
I could only use my cellphone...)

> I think we are going nowhere on linux-pm at the moment, we won't solve
> world hunger with endless discussions aimed toward designing the
> ultimate scheme that will solve all problems at once. 

Well, I don't think it is "getting nowhere". I believe we pretty much
agreed on what we want to do, and are simply waiting for 2.6.10 to
open so patch can start to flow? 

> What about changing the whole thing in a way a bit closer to what darwin
> does and in a way that will preserve existing drivers, making a smoother
> transition (basically defining a _new_ callback) ? that means deciding
> suspend() and resume() callbacks are obsolete but still supported by a
> default mecanism when the new stuff is not there while adding a new
> set_power_state() callback. The transition would be easy as not breaking
> existing drivers.

I think you meant Darwin (evolution theory), not Darwin (MAC OS X
part)?

Anyway, current proposal has smooth way to get in, it just requires
few steps. OTOH, each of those steps is improvement over previous
case, and (if previous steps are done correctly) breaks nothing.

Step 1: introduce type checking for suspend_message_t, pci_power_t and
similar beasts.

Step 2: fix all the drivers. When they assign from suspend_message_t
to pci_power_t, make them call helper (pci_choose_state()). This
applies to USB, too, BTW; if their devices are only interested if they
are going to get powered down or not, let them have
usb_will_i_be_powered_down_p(suspend_message_t state).

Step 3: switch from typedef int suspend_message_t to typedef struct
... suspend_message_t, and fix the few pci_power_t (and similar)
functions. We are done at this point.

Hmm, fixing USB will be little trickier, as they do not have any info
passed down their suspend() callbacks... They really should pass
suspend_message_t down to the drivers.

> The idea is simple. Drivers describe their possible power states in an
> array, which contains:
> 
>  - state name (ascii) for use by sysfs (see below)
>  - some flags (for later use mostly)
>  - matching system state
>  - additional infos (see below), that is struct can be extended for
> later uses.

These arrays are going to get big and ugly over time.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux