On Friday, 4 May 2007 16:40, Alan Stern wrote: > Rafael, David, and Pavel: > > You all misunderstood the point I was trying to make. > > On Thu, 3 May 2007, Rafael J. Wysocki wrote: > > > > But why shouldn't a "normal" poweroff enter ACPI S4? And why shouldn't a > > > "hibernate" poweroff enter ACPI S5? The choice of which state to enter is > > > independent of the reason for shutting down, right? > > > > Well, not exactly. > > > > > In other words, the choice for whether or not to call > > > acpi_enter_sleep_state(ACPI_STATE_S4) shouldn't depend on whether or not > > > you're hibernating. So it shouldn't affect the usage of hibernation_ops > > > at all. > > > > This works the other way around, I think. :-) > > > > Granted, some boxes require us to call acpi_enter_sleep_state(ACPI_STATE_S4) > > as a 'power off method' so that they work correctly after the 'return' from hibernation. > > If we do acpi_enter_sleep_state(ACPI_STATE_S5) instead, some things might > > not work on them (this is an experimental observation, I don't know what > > exactly the reason of it is). > > > > Now, since I have such a box, I need to do the > > acpi_enter_sleep_state(ACPI_STATE_S4) thing (IOW, use the 'platform' power off > > method) and not acpi_enter_sleep_state(ACPI_STATE_S5) (the 'shutdown' power > > off method). *However*, acpi_enter_sleep_state(ACPI_STATE_S4) cannot be used > > without previous preparations, which are made with the help of hibernation_ops. > > > > IOW, all hibernation_ops, including the ->enter() method that actually calls > > acpi_enter_sleep_state(ACPI_STATE_S4), are just different pieces of one > > (complicated) 'platform' power off method. It doesn't make sense to use the > > (other) hibernation_ops without the ->enter() method. > > Let's look at the big picture. > > Entering hibernation basically involves these steps: > > 1. Freeze tasks > > 2. Quiesce devices and drivers > > 3. Create snapshot > > 4. Reactivate devices and drivers > > 5. Save snapshot to disk > > 6. Prepare devices for wakeup > > 7. Power down (ACPI S4 on systems which support it) > > Leaving hibernation involves a similar sequence which I won't discuss. > > Notice that steps 1-5 above are _completely_ independent of all issues > concerning wakeup devices and S4 vs. S5 vs. whatever. They have to be > carried out for hibernation to work, no matter how the system ends up > getting shut down. > > On the other hand, steps 6 and 7 aren't really needed for hibernation. > You _could_ shut the system off completely (ACPI S5). Automatic wakeup > wouldn't work, but the next time the user turned the computer on manually > it would still resume from hibernation. That's correct, with the exception that the user may find the system not fully functional after the resume in that case. > Conversely, steps 6 and 7 can make sense even in situations where you > don't want to hibernate. For example, you might want a normal shutdown in > which the operating system does a full restart when the firmware is > signalled by a wakeup device. > > So there should be separate data structures associated with 1-5 and 6-7. > Maybe the one associated with 6-7 is what you are calling hibernation_ops; > if so then fine. But I still think that it should be usable for > situations where you are not entering hibernation, and we should be > possible to enter hibernation without using it. The system administrator > should be able to choose which of S4 or S5 gets used for _any_ poweroff, > regardless of whether it's to start hibernating. Yes, this should be doable. > The ACPI spec might refer to S4 as "hibernation" (does it? -- I'm too lazy > to check and see), Not directly. The word "hibernation" is never used in the ACPI specification (as of ACPI 2.0). > but that doesn't mean we have to use the terms synonymously. Agreed. > Does this make sense, or am I missing something very basic? Hmm, I think it makes sense. Greetings, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
