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 thesys_kexe_load is called to load the kernel image, thensys_reboot(LINUX_REBOOT_CMD_KEXEC) is called to boot the new kernel. Thecall chain is as follow:

In device_shutdown, the dev->bus->shutdown or dev->driver->shutdown ofevery device is called to put device in quiescent state. Inmachine_kexec, the new kernel is booted.

So, for normal kexec, there is no code path for device state saving andrestoring. State of device can be restore after shutdown? I don't thinkso.

> 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 interestedin this subject. But I think we should try to verify our idea with codeas early as possible. Now, I am trying to implement a prototype ofkexec/kdump based image writing/reading mechanism to verify thefeasibility. (I suppose you are working on separating device suspend anddevice 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".