public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Anomalous Force <anomalous_force@yahoo.com>
To: wa@almesberger.net
Cc: ebiederm@xmission.com, linux-kernel@vger.kernel.org
Subject: Re: holy grail
Date: Thu, 26 Dec 2002 23:21:42 -0800 (PST)	[thread overview]
Message-ID: <20021227072142.26177.qmail@web13208.mail.yahoo.com> (raw)
In-Reply-To: <20021227010338.A1406@almesberger.net>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 2382 bytes --]


--- Werner Almesberger <wa@almesberger.net> wrote:

[snip]

> An older or newer kernel would have different data structures, and
> possibly even data structures which are arranged in a different way
> (e.g. a hash becomes some kind of tree, etc.). So you'd need some
> translation mechanism that "upgrades" or "downgrades" all kernel
> data, including all pointers and offsets that may be sitting
> around somewhere. Good luck :-)

what if the new kernel asked the old kernel to hand over the data in
a form that was understood universally beginning at some kernel
version X (earliest supported kernel in other words). the data
would not have to remain in the optimized form that it would reside
in while under normal operations. it could be serialized as such into
a form that simply contains its content and context. im thinking of
something along the lines of a data packet (tcp/ip comes to mind)
that contains data about its data. a structure similar to that, which
conveys information describing the data its contains. any mechanisms
the newer kernel may institute would get set to a default state
similar to booting just that portion of the kernel.

> 
> Your best bet would be to use a system that already implements some
> form of checkpointing or process migration, and use this to
> preserve user space state across kexec reboots. openMosix may be

[snip]

preserving user state would not be so much the problem as would
the various internal kernel data structures (vm stuff, dcache, etc.)
the issue here is to freeze the system state, sys calls, irqs, and
all, and restart the same state where it left off after the switch.
the kernel would not need to boot, as an initial boot has already
been done by the previous kernel.

yes, it would be extremely difficult. but, as with all fields of
endevour, a holy grail is only such because it is. the question
remains, is this do-able? perhaps not now, or in two years, but
what about five? say, kernel 3.x.x or even 4.x.x?


=====
Main Entry: anom·a·lous 
1 : inconsistent with or deviating from what is usual, normal, or expected: IRREGULAR, UNUSUAL
2 (a) : of uncertain nature or classification (b) : marked by incongruity or contradiction : PARADOXICAL
synonym see IRREGULAR

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

  reply	other threads:[~2002-12-27  7:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-27  0:51 holy grail Anomalous Force
2002-12-27  4:03 ` Werner Almesberger
2002-12-27  7:21   ` Anomalous Force [this message]
2002-12-27  7:37     ` Ingo Oeser
2002-12-27 11:30     ` Werner Almesberger
2002-12-28 16:35       ` Anomalous Force
2002-12-28 20:43         ` Rik van Riel
2002-12-29 15:56           ` Anomalous Force
2002-12-29 16:44             ` John Bradford
2002-12-30  1:05           ` Alan Cox
2002-12-30  1:32             ` Werner Almesberger
2002-12-30  2:45               ` Jeff Dike
2002-12-30  3:55                 ` David Lang
2002-12-30  4:39                   ` Anomalous Force
2002-12-30 17:57                     ` Eric W. Biederman
2002-12-30 13:30               ` Alan Cox
2002-12-29 23:53         ` Werner Almesberger
2002-12-27 13:24     ` Pavel Machek
  -- strict thread matches above, loose matches on Subject: below --
2002-12-30  5:00 Anomalous Force
2002-12-30  6:46 ` Ed Sweetman

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=20021227072142.26177.qmail@web13208.mail.yahoo.com \
    --to=anomalous_force@yahoo.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wa@almesberger.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox