From: Jeff Dike <jdike@karaya.com>
To: Werner Almesberger <wa@almesberger.net>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Rik van Riel <riel@conectiva.com.br>,
Anomalous Force <anomalous_force@yahoo.com>,
ebiederm@xmission.com,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: holy grail
Date: Sun, 29 Dec 2002 21:45:52 -0500 [thread overview]
Message-ID: <200212300245.VAA04199@ccure.karaya.com> (raw)
In-Reply-To: Your message of "Sun, 29 Dec 2002 22:32:47 -0300." <20021229223247.C1363@almesberger.net>
wa@almesberger.net said:
> I see a certain trend towards mechanisms that can be useful for
> process migration. E.g. the address space manipulations discussed for
> UML seem to allow almost perfect reconstruction of processes. PIDs,
> signals, anything with externally visible changes in kernel state
With a UML running in skas mode, the process address space is identical to
what it would be on the host. Migrating one to the host would be a matter
of
Sticking a process in it
Releasing that process from ptrace
Recreating the required kernel state in the host kernel
Kicking the process out of the UML kernel and into userspace somehow
Letting it run
Step 3 is obviously where the meat of the problem is. The process needs
to have available on it all the resources it had in UML -
the same files
network connections (puntable on a first pass)
process relationships (I have no idea what to do about a parent
process on the host, nor what to do with children whose parent has been
migrated, or ipc mechanisms, except to do the Mosix thing and have little
proxies sitting around passing information between UML and the host).
And since I've brought up Mosix, as did Werner, the fastest way to get
this working is probably to finish off the OpenMosix/UML port (which was
close from what I heard), and cluster a UML and its host. You should get
process migration for free.
Just remember to prevent the host from trying to migrate a UML to itself.
That would be very bad.
Jeff
next prev parent reply other threads:[~2002-12-30 2:45 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
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 [this message]
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=200212300245.VAA04199@ccure.karaya.com \
--to=jdike@karaya.com \
--cc=alan@lxorguk.ukuu.org.uk \
--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