All of lore.kernel.org
 help / color / mirror / Atom feed
From: kaih@khms.westfalen.de (Kai Henningsen)
To: linux-kernel@vger.kernel.org
Subject: Re: Switching Kernels without Rebooting?
Date: 12 Jul 2001 09:23:00 +0200	[thread overview]
Message-ID: <84jaVrwXw-B@khms.westfalen.de> (raw)
In-Reply-To: <Pine.LNX.4.33L.0107111913010.9899-100000@imladris.rielhome.conectiva>
In-Reply-To: <Pine.LNX.4.33.0107112310590.962-100000@fogarty.jakma.org> <Pine.LNX.4.33L.0107111913010.9899-100000@imladris.rielhome.conectiva>

riel@conectiva.com.br (Rik van Riel)  wrote on 11.07.01 in <Pine.LNX.4.33L.0107111913010.9899-100000@imladris.rielhome.conectiva>:

> One thing which always surprises me in this discussion
> (it comes up about once a year, it seems) is that
> nobody participating in this discussion ever starts
> writing any code for it.
>
> Is this a feature which is only wanted by people who
> don't want to code, or is this just a signal that the
> amount of trouble involved just isn't worth it?

Maybe it's a sign that the people who *would* be able to contribute have  
all looked at the problem already (surely most people are annoyed how a  
reboot interrupts everything), and have already concluded for themselves  
that it's not possible with reasonable effort ... but there is a steady  
influx of new people who don't understand enough of the problem and have  
to ask.

What I'd *really* like (but don't see how to get there) would be a "save  
system state, shutdown, change kernel and/or hardware, reboot, restore  
state" system (where state is like "I'm logged in on this console, in this  
current directory, and under X I have Netscape running and this page  
displayed" but I don't care about the exact state of Squid or even if my  
ISDN line is dialled in, because those "fix themselves").

I suspect to do this right would need a means of storing per-process state  
controlled by the process (because only that process knows what needs to  
be saved, and what can easily be reconstructed - for example, open file  
descriptors to a place where we store cookies don't need to be saved, just  
routinely reopened), and then every user-visible non-transient program  
needs to implement it - and I don't see *that* happen in the next ten  
years.

But it *does* have the advantage of not needing to save kernel-internal  
state.

MfG Kai

  parent reply	other threads:[~2001-07-12  7:15 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <NOEJJDACGOHCKNCOGFOMOEKECGAA.davids@webmaster.com>
2001-07-10 20:43 ` Switching Kernels without Rebooting? C. Slater
2001-07-11  3:50   ` FORT David
2001-07-11  9:10   ` Helge Hafting
2001-07-11 15:41     ` C. Slater
2001-07-11 18:11       ` Switching Kernels without Rebooting? [MOSIX] Carlos O'Donell Jr.
2001-07-12 10:16       ` Switching Kernels without Rebooting? Helge Hafting
2001-07-11 22:12     ` Paul Jakma
2001-07-11 22:14       ` Rik van Riel
2001-07-11 22:36         ` C. Slater
2001-07-11 23:44           ` Andreas Dilger
2001-07-12  1:17             ` C. Slater
2001-07-12 15:39               ` Rik van Riel
2001-07-12 16:23                 ` Albert D. Cahalan
2001-07-12 17:37                   ` Mike Borrelli
2001-07-12 18:05                   ` Rik van Riel
2001-07-13 10:07                     ` Pau Aliagas
2001-07-12 18:48                   ` Chris Friesen
2001-07-12 10:12             ` Ralf Baechle
2001-07-12 15:32           ` Rik van Riel
2001-07-11 22:36         ` David Schwartz
2001-07-12  7:23         ` Kai Henningsen [this message]
2001-07-12 10:05           ` Helge Hafting
2001-07-13  6:50             ` Kai Henningsen
2001-07-12 17:58           ` Hua Zhong
2001-07-12 23:24           ` swsusp again [was Re: Switching Kernels without Rebooting?] Pavel Machek
2001-07-13 21:08             ` Alan Cox
2001-07-11 22:46       ` Switching Kernels without Rebooting? Kip Macy
2001-07-11 23:02         ` Rik van Riel
2001-07-12  0:31         ` Jesse Pollard
2001-07-12  1:10           ` Hua Zhong
2001-07-11 23:36       ` H. Peter Anvin
2001-07-12  7:23       ` Ville Herva
2001-07-13  1:11 tas
2001-07-13  3:45 ` Ian Stirling
  -- strict thread matches above, loose matches on Subject: below --
2001-07-12 15:32 Jesse Pollard
2001-07-12 12:23 Jesse Pollard
2001-07-12 14:55 ` Ralf Baechle
2001-07-12  4:48 Frank Davis
2001-07-12  5:08 ` John Alvord
2001-07-13  9:10   ` Chuck Hemker
2001-07-12  1:03 Torrey Hoffman
2001-07-12  1:24 ` C. Slater
2001-07-12 10:07   ` Jesse Pollard
2001-07-12 12:11     ` Ian Stirling
2001-07-12 12:54       ` Jesse Pollard
2001-07-12 14:15         ` Michael H. Warfield
2001-07-12 23:17   ` Pavel Machek
2001-07-12 20:47 ` Wilfried Weissmann
     [not found] <994895240.21189@whiskey.enposte.net>
2001-07-12  0:10 ` Stuart Lynne
2001-07-11  9:52 David Balazic
2001-07-11 10:08 ` Laramie Leavitt
2001-07-11 19:12   ` H. Peter Anvin
2001-07-11 15:19 ` C. Slater
2001-07-10 18:42 C. Slater
2001-07-10 18:50 ` Chris Wedgwood
2001-07-10 21:11 ` Jesper Juhl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84jaVrwXw-B@khms.westfalen.de \
    --to=kaih@khms.westfalen.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.