On Thu, 12 Jul 2007, Rafael J. Wysocki wrote:
I didn't understand the ACPI problem. Does this mean that CONFIG_ACPI must
be disabled in the to-be-hibernated kernel, or in the little transient
kexec kernel?
Under current implementation of device state quiescent/save/restore, the
CONFIG_ACPI must be turned off both in to-be-hibernated kernel and
transient kexec kernel.
But the hibernation people are going to separate the device suspend from
device hibernate. The device hibernate will put device in quiescent
state but not in low power state. When this is done, it is not necessary
to disable CONFIG_ACPI at all. It is just a workaround for current
implementation that disabling CONFIG_ACPI.
How close do you think all this is to being a viable thing?
The kexec jump is the first step, maybe the simplest step. There are
many other issues to be resolved, at least the following ones.
1. Separate device suspend from device hibernate.
Step 0, I'd say. :-)
is there more involved then just start ignoreing device hibernate and just
useing the device suspend? (although if there is not a workable device
suspend for a driver, that would answer my question :-)
2. Do not reserve memory for kexec kernel. That is, backup needed memory
before kexec and restore them after kexec.
I don't think this is very important initially.
I agree, a stipped down hibernate kernel can be very small, not allocating
this memory until it's needed is a step for the final polishing.
3. Support the in-place kexec? The relocatable kernel is not necessary
if this can be implemented.
4. Image writing/reading. (Only user space application is needed).
And a kernel interface for that application.
I do't understand this statement, this application is just useing the
standard kernel interfaces (block devices to read/write to disk, network
devices to read/write to a server, etc). no new interfaces needed.
5. A smooth resume process. Maybe it is not needed to kexec a new kernel
for resume. For example, in the first stage of kernel boot, just first
16M (or a little more) RAM is used, if the resume image is found, the
saved kernel image is resumed; if the resume image is not found, turn on
the remaining RAM. This will depends on 3.
I think that this is the most difficult part of the whole thing.
don't try to get too fancy right now. stick with a simple 'boot hibernate
kernel, it's userspace looks for an image to resume, and if it doesn't
find one reboot to the normal system'
I don't know how to do this with grub, but it would be a trivial shell
script with lilo
6. Reduce the boot-up time of kexec kernel. Maybe the kexec kernel can
be hibernate/resume by the normal kernel too. This way, a real
kexec/boot-up is only needed for the first time.
I'm not sure what you mean.
he's trying to get fancy again, the best way to speed up the boot of the
kexec kernel is make it smaller and avoid probing for devices (hotplug
should NOT be used for normal suspend situations)
David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
