Hi again. On Fri, 2008-05-16 at 11:26 +0200, Stefan Seyfried wrote: > Nigel Cunningham wrote: > > Hi. > > > > On Fri, 2008-05-16 at 10:42 +0200, Stefan Seyfried wrote: > > >> Remember, refusing to suspend should only happen in very rare cases, i > >> currently only have a few for suspend to disk: > >> - the kernel changed (security update), so we know before suspend that we > >> can't resume > > > > Some code went into vanilla around 2.6.23 IIRC which allows us to resume > > from a different kernel version, so this shouldn't be an issue anymore. > > Ok, so one less reason to refuse to suspend. (I'm conservative about that > unless i have heavily tested it, though).
Fair enough, too. I need to do more testing of it myself. Making software flexible is nice, but it makes for even more combinations for testing :\ > >> - there is no swap partition or more generally no storage for s2disk > >> configured => configuration error > > > > Mmm. Not necessarily an issue for TuxOnIce though, as the user can be > > writing to a file rather than swap (yeah, I know you don't care Stefan, > > but maybe the others do). > > "or more generally no storage for s2disk". I'm sure there are scenarios for > tuxonice where you know in advance that calling the suspend method in the > kernel does not make sense. Yes. > ... actually even then, the kernel (or "s2disk") should just return with an > error code and we can display a hint for the user derived from the error code. That's what I try to do. I have a 'last_result'' sysfs entry people can read (but it's a bitmap innterpreted by the hibernate script). I have on my todo list to add a nicer explanation to /sys/power/tuxonice/debugging_info before the next release. > >> "Being unable to apply video workarounds before s2ram" generally cannot > >> happen > >> IMVHO (but i'm ready to be convinced the other way round). > >> > >> Right now, just refusing to suspend and then later exiting with != 0 exit > >> code, so that the GUIs can display a "suspend had a problem, do you want to > >> look at the Log file / file a bugreport?" message was pretty effective and > >> worked very well for me. > > > > Sounds good to me, too. > > And that is what was in the code all the time (unless it was removed recently, > i have not verified it) without making the hook-running code more complex and > the rules that hook-writers have to obey more complicated. > > Have fun, You too :) Nigel _______________________________________________ Pm-utils mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pm-utils
