Matthew Dillon wrote:
> Well, I don't want do disuade you from trying, but I think you are
> seriously underestimating the effort required to restore device state.
>
> You basically would either have to make all device drivers support a new
> hibernation/restore API (because it is not really possible to restore
Shouldn't it be very similar to the suspend API?
> a device driver based on a dump), or you would need to implement some
> higher level utility code (e.g. scripts and such) to try to record and
> restore the state at a higher level, such as for network interfaces,
> and not allow any restored processes to run until that's done. Either
> way it would get messy very quickly.
>
> Also, if the machine has a lot of memory it could take longer to save
> and restore then to reboot from scratch. A typical laptop HD is
Indeed true, but when I use windows hibernate I don't intend to
simply bypass boot procedures, I want to keep the workspace active. If
the workspace is not important, I simply shutdown, as it is also a
profilatic memory cleaning. ;-)
> I think it would probably be more realistic to persue a process
> save/restore rather then a kernel save/restore. The overhead is going
> to be the disk I/O anyway and that seems to be about the same either
> way (maybe less for a process restore), plus you can at least demand-load
> the process restore.
Let's suppose I want to keep my X desktop intact. Should I
save/restore processes in which order? X server or X clients? They
need to interact with each other, and if one try to interact while the
other has already "died", it will simply close and die too. That's why
I think a kernel save/restore is better for a full hibernation
situation. Of course single process hibernation is also useful! I am a
very old user, from the times where LaTeX had to core dump after
initializing variables to startup faster later. ;-)
Jonny
--
João Carlos Mendes Luís - Networking Engineer - jonny at jonny.eng.br