From owner-freebsd-hackers  Wed Oct 25 06:19:03 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id GAA13368
          for hackers-outgoing; Wed, 25 Oct 1995 06:19:03 -0700
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA13358
          for <hackers@freefall.FreeBSD.org>; Wed, 25 Oct 1995 06:19:00 -0700
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id GAA27314; Wed, 25 Oct 1995 06:17:07 -0700
To: Gavin Lim <gavin@linux1.dlsu.edu.ph>
Cc: hackers@freefall.FreeBSD.org
In-reply-to: Your message of "Tue, 24 Oct 1995 19:22:56 PDT."
             <199510250226.TAA19363@freefall.freebsd.org> 
Date: Wed, 25 Oct 1995 06:17:07 -0700
Message-ID: <27312.814627027@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-hackers@FreeBSD.org
Precedence: bulk

> In order to transfer a process, we have to save the process state, 
> probably save it to a file, and transfer this file to the destination 
> computer, where it would be deserialized and converted back to data 
> structures.  When this is done, the process can resume execution on the 
> destination computer.

Ah, my favorite axe to grind! :-)

[ everyone else covers their eyes: "Oh no!  Not this again!" :) ]

Yes, you've stumbled onto one of the "hard problems" that a lot of
UNIX vendors have simply punted on after examining it.  It's not a
trivial one and solving it will take a fairly fundamental re-think
about how a process' "relationship" with the host computer is handled.

The biggest bugaboo is the file table.  Assuming that saving the
process text, data and stack information is a problem you've solved
(which would either require that we stop paging directly out of
executables or that the relationship between process and executable
became rather more abstract) you've still got to worry about all the
files it has open and its controlling TTY.  What happens when the
image is reactivated on the other host?  Do its file I/O requests to
any now non-local files go back to the original host, do you assume a
homogenous AFS-like file system for which all files have universal
IDs, or what?  The Sprite project's efforts to solve this problem
ended up producing a system that didn't look much like UNIX anymore!

In other words, I doubt that the people on this list are going to be
able to help you all that much, at least not relative to our current
code base.  You have some substantial re-architecting ahead of you!

					Jordan