From: Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
To: linux-kernel@vger.kernel.org
Subject: Re: kernel upgrade on the fly
Date: Thu, 20 Jun 2002 15:40:57 -0500 (CDT) [thread overview]
Message-ID: <200206202040.PAA23348@tomcat.admin.navo.hpc.mil> (raw)
zaimi@pegasus.rutgers.edu:
>
> Thanks for the responses especially Rob. I was trying to find previous
> threads about this and could not find them. Agreed, swsusp is a step
> further to that goal; the way that memory is saved though may not make it
> necessarily easier, at least in the current state of swsusp.
>
> As you were mentioning, the processes information needs
> to be summarised and saved in such a way that the new kernel can pick up
> and construct its own queues of processes independent on the differences
> between the kernels being swapped.
>
> Well, this does touch the idea of having migrating processes from one
> machine to others in a network. In fact, I dont understand why is it so
> hard to reparent a process. If it can be reparented within a machine, then
> it can migrate to other machines as well, no?
No.
Reparenting a process only changes the identity of the parent reference of a
process.
Migrating to another machine has to handle (at a minimum):
1. open files - file id, file pointer values must be moved.
2. network connections must be redirected, existing queues must be transferred
3. shared memory segment references must be transferred, possibly even the
file referenced by mmap operations (see item 5)
4. semaphores must be transferred
5. disk files may have to be transferred (currently open files in /tmp ?)
6. pipes to other processes must be re-established, as the current contents
of any pipe buffers, and even the other process(s) attached to the pipe
7. process kernel stack must be preserved (current syscall activity?) and
process control block state
8. the curren process data must be transferred (memory image, shared
library references)
9. recreating the same/equivalent process context (pid, ppid,uid,gid, and
all the kernel setup may/will have to be transferred)
A lot of things NOT mentioned (what about the active buffer cache for open
files... shared file access...)
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
next reply other threads:[~2002-06-20 20:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-20 20:40 Jesse Pollard [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-06-20 20:19 kernel upgrade on the fly zaimi
2002-06-21 13:42 ` Rob Landley
2002-06-18 21:21 zaimi
2002-06-18 19:37 ` Rob Landley
2002-06-19 5:09 ` Michael S. Zick
2002-06-19 17:22 ` John Alvord
2002-06-19 16:56 ` Rob Landley
2002-06-22 8:40 ` Pavel Machek
2002-06-22 8:34 ` Pavel Machek
2002-06-18 21:30 ` Russell King
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=200206202040.PAA23348@tomcat.admin.navo.hpc.mil \
--to=pollard@tomcat.admin.navo.hpc.mil \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox