Re: Re: swsusp issues

[Nigel Cunningham <ncunningham@cyclades.com>]

[-- Attachment #1: Type: text/plain, Size: 1792 bytes --]

Hi.

On Sat, 2005-06-04 at 08:50, Benjamin Herrenschmidt wrote:
> > PM_DISK_REBOOT is very usefull for testing (and I believe generic; you
> > could do that on ppc too). PM_DISK_SHUTDOWN is usefull for using
> > normal powerdown paths in case something is wrong with disk-specific
> > powerdown. We should move away from it, but please try not to kill it.
> 
> Well, I have a problem with these because they don't call the arch
> prepare/finish callbacks.
> 
> Anyway, I discussed with Patrick yesterday and we came to the conclusion
> that the best is in fact to just kill the current mecanism which was
> done upside down. Kill pm_ops completely and instead of having a slim
> "core" that uses callbacks all over, have the arch contain the main
> state enter function and have the stuff in kernel/power/* be "library"
> functions to be called by the arch code.
> 
> The idea here is then to have the arch provide main.c with an array of
> "name",function pairs (name beeing the name in /sys/power/state and
> function is what to call when the user echo's that name
> to /sys/power/state). The rest would be entirely under arch control, and
> that would remove most of the current cruft.
> 
> To simplify the job for swsusp and avoid the ugly in_suspend thing, we
> should do a slight change of the low level code so that swsusp_suspend()
> returns: 0 -> resume, 1 -> snapshotted, <0 -> error
> 
> We could provide an "example" default implementation that does only
> swsusp that an arch can "drop in" if you want, but archs have to
> implement the various "inline" callbacks anyway (save_processor_state &
> friends).

How could I work with that in an implementation where the vast majority
of the code is arch-independent? I guess I'll have to see what you come
up with.

Regards,

Nigel


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]