On Tue, Jan 25, 2005 at 09:45:43PM +, Steven Smith wrote:
> Also, have you ever looked at the live migration stuff Xen uses? The
> aim here is to move a running operating system from one machine to
> another with minimal downtime. Essentially, you just start copying
> pages across willy nilly
On Tue, 25 Jan 2005 21:45:43 +
Steven Smith <[EMAIL PROTECTED]> wrote:
> If you just send pages to disk rather than to another machine on the
> network, then you should be able to suspend-to-disk an entire
> operating system with minimal user-perceived downtime. One
> possibility here would b
> You basically would either have to make all device drivers support a new
> hibernation/restore API (because it is not really possible to restore
> a device driver based on a dump),
How much overlap is there likely to be between this and the sorts of
things you need in order to resume
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
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
--- [EMAIL PROTECTED] wrote:
[snip]
>
> Well booting the kernel generally takes little time,
> but if all the
> processes could be restored this would be a step in
> the right direction.
If restoring a previously executing program can
recover some *context*, then it makes sense to
restore. If y
In message <[EMAIL PROTECTED]>, Christian Laursen wrote:
>I was thinking about software suspend and got this crazy idea.
Not so crazy Idea.
>I have no idea if this is possible or total madness but here
>goes anyway.
>
>The idea would be to force the system to "crash" and make a
>dump on a dedicat
On Tue, Jan 25, 2005, Bruce M Simpson wrote:
> If we could take a clean subsystem-by-subsystem approach to marshaling
> kernel state to disk, that would be good. What gives me particular pain
> here is dealing with things like the filesystem. How does one deal with
> open files, etc, with pending I
On Mon, Jan 24, 2005 at 07:37:34PM -0600, Ryan Sommers wrote:
> My little knowledge on this subject aside. I'd love to have full
> suspend/resume functionality. It'd make my life as a mobile freebsd user
> much much easier. However, I wouldn't want it at the expense of every
> kernel. It would n
João Carlos Mendes Luís wrote:
Isn't it much easier to simply reload the full memory dump (hibernation
file, not dump device) into RAM and continue from that point? This
should be done by /boot/loader, not by a full kernel, as the memory dump
will also contain the kernel.
At this point, all yo
Isn't it much easier to simply reload the full memory dump (hibernation
file, not dump device) into RAM and continue from that point? This
should be done by /boot/loader, not by a full kernel, as the memory dump
will also contain the kernel.
At this point, all you have to do is to restore the
:Well booting the kernel generally takes little time, but if all the
:processes could be restored this would be a step in the right direction.
:As John said, restoring the state of some programs will have to rely on
:the program, but perhaps this could lead to an API of some sort that would
:make t
> It is not really doable to try to restore a kernel core dump. The
> problem is that once the kernel has booted to the point where it can
> check the core, it's memory will already contain hundreds if not
> thousands of data structures related to booting and you can't just
>
:...
:I'm not interested in resuming after a real crash. The idea is
:to get suspend/resume functionality without hardware support.
:
:So there would be no panic, but the system would be brought to
:a halt and the memory dumped.
:
:> Also the devices wouldn't be in the state they had been in at
:>
On Tue, 25 Jan 2005, Peter Jeremy wrote:
> On Mon, 2005-Jan-24 20:22:27 +0100, Christian Laursen wrote:
> >The idea would be to force the system to "crash" and make a
> >dump on a dedicated partition. On boot after initializing devices
> >but before mounting /, the kernel would check that partitio
Dominic Marks <[EMAIL PROTECTED]> writes:
> Christian Laursen wrote:
> > I was thinking about software suspend and got this crazy idea.
> > I have no idea if this is possible or total madness but here
> > goes anyway.
> > The idea would be to force the system to "crash" and make a
> > dump on a de
On Mon, 2005-Jan-24 20:22:27 +0100, Christian Laursen wrote:
>The idea would be to force the system to "crash" and make a
>dump on a dedicated partition. On boot after initializing devices
>but before mounting /, the kernel would check that partition and
>if it found a dump there restore it to the
On Mon, 24 Jan 2005, Christian Laursen wrote:
> The idea would be to force the system to "crash" and make a
> dump on a dedicated partition. On boot after initializing devices
> but before mounting /, the kernel would check that partition and
> if it found a dump there restore it to the machine's
18 matches
Mail list logo
