On Mon, 2007-07-16 at 14:17 +0200, Rafael J. Wysocki wrote:
> > is this a matter of running some test to find out, or is this a question
> > for the kexec implemantors?
>
> Actually, I'd like someone to tell me. ;-)
>
> I've browsed the kexec code, but haven't found anything related to the devices
> in it. Perhaps I didn't know where to look ...
There are two stages for kexec. For "normal" kexec, first the
sys_kexe_load is called to load the kernel image, then
sys_reboot(LINUX_REBOOT_CMD_KEXEC) is called to boot the new kernel. The
call chain is as follow:
sys_reboot(LINUX_REBOOT_CMD_KEXEC)
kernel_kexec
kernel_restart_prepare
device_shutdown
machine_shutdown
machine_kexec
In device_shutdown, the dev->bus->shutdown or dev->driver->shutdown of
every device is called to put device in quiescent state. In
machine_kexec, the new kernel is booted.
So, for normal kexec, there is no code path for device state saving and
restoring. State of device can be restore after shutdown? I don't think
so.
> I think that the right approach is to separate devices' suspend from the
> devices' hibernation-related operations FIRST. Then, many different approaches
> to hibernation will be much easier to implement than they are now.
>
> I've been saying this for weeks now, but no one seems to listen frankly I'm
> tired of repeating it:
I agree with you on this. :)
> If we want to improve things, let's do that IN AN ORDERED WAY. If everyone
> will come up with a new idea every two days, we won't be able to get anything
> actually _done_.
Yes, and I am very glad to collaborate with everybody who is interested
in this subject. But I think we should try to verify our idea with code
as early as possible. Now, I am trying to implement a prototype of
kexec/kdump based image writing/reading mechanism to verify the
feasibility. (I suppose you are working on separating device suspend and
device hibernate).
What do you think about the pattern of collaboration?
At last, thank you very much for your valuable reminding in the mail of
"hibernation considerations".
Best Regards,
Huang Ying
-
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]
