On Thursday 22 March 2007 3:10 pm, Rafael J. Wysocki wrote: > Well, I think the only clear distinction between the STR and "standby" is the > necessity to go through a boot-like procedure in order to resume from the > former. So what's a "boot-like procedure"? Ten instructions? A hundred? A thousand? Ten thousand? Does it take a certain amount of time? Does it perform certain operations? Does it involve going through ACPI (or APM)? If so, what about the fact that ACPI (or APM) are involved in "standby" resumes too (on platforms using them)? And why wouldn't a standby mode be able to do any or all of those? > So, I'd tend to think the STR is when the CPU(s) is(are) powered > down and if some platforms don't support that, they just don't support the > STR. That seems like a counterproductive restriction. The only reason to adopt it is if you care so much about ACPI that you insist on using their state definitions even on systems that will never use ACPI. For a system that supports several power saving modes but doesn't have the ability to turn the CPU off, what conceivable value would there be in saying it's not OK to use the "STR" label for any of those states? And thus, to say that the system is only **allowed** to expose one of those power saving modes to Linux ... and that it must always be called "standby"? Even if, from an external perspective, it acts just like an STR would act? My answer: there is NO value to such an arbitrary restriction. > Also, I'd like to define "standby" and STR as system-wide low power states > which involve the freezing of processes before entering them. That should go without saying, since "echo NAME > /sys/power/state" does that regardless of NAME. - Dave _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
