On Wed, 2008-03-12 at 00:49 +0100, Rafael J. Wysocki wrote: > On Wednesday, 12 of March 2008, Pavel Machek wrote: [...] > > > > Its certainly "more traditional" method of doing hibernation than > > tricks swsusp currently plays. > > What exactly are you referring to? Long long ago, the hibernation is not done by Linux kernel itself but BIOS (APM). Those days, kernel just does some preparation and jump to BIOS to do the hibernation. Imagine kernel B is the hibernation BIOS, kernel A does some prepare and jump to the BIOS (kernel B) just like the old days. > > Yes, I'd like these patches to go in, being able to switch kernels seems like > > useful tool. > > No objection from me. > > > Now, I guess they are some difficulties, like ACPI integration, and > > some basic drawbacks, like few seconds needed to boot second kernel > > during suspend. > > > > ...OTOH this is probably only chance to eliminate freezer from > > swsusp... > > Some facts: > > * In order to be able to do suspend (STR) without the freezer, we need to make > device drivers block access to devices from applications during suspend. > * There's no reason to think that we can't use this same mechanism for > hibernation (the only difficulty seems to be the handling of devices used for > saving the image). I think "kexec based hibernation" is the only currently available possible method to write out image without freezer (after driver works are done). If other process is running, how to prevent them from writing to disk without freezing them in current implementation? > * We need the drivers to quiesce devices to be able to do the kexec jump in the > first place (and to avoid races, we'll need them to block applications' > access to devices just like for STR, which is the sufficient condition for > removing the freezer). > > So, I don't really think that the "freezer removal" argument is valid here. > > Moreover, if this had been the _only_ argument for the $subject functionality, > I'd have been against it. Best Regards, Huang Ying _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
