PROCESS MIGRATION IN UNIX

[Frobozz]

In <1990Dec12.181012.17399 at cs.wayne.edu> tnk at athena.cs.wayne.edu (Tahir N. Khan) writes:




>    I've been looking into some very simple process migration
>	techniques. Since I am not a unix expert I was wondering if
>	anyone out there has any information on how to access
>	the state of a process including registers and execution state,
>	virtual memory, and file access.

>	Any leads to the required steps or what system calls should be 
>	used,if any, will be greatly appreciated.

Accessing process state isn't very difficult.  Either you can make the
process access the necessary state itself or another processes can grab
the information.  Considering these in order.

Letting the process get its own state info:
	This allows for a very easy access to mundane things like the
	registers and execution state and the entire address space of the
	process (finding the bounds on this address space is more interesting)
	For the more specialised stuff, you've got to access what is called the
	u-page that contains the per-process information that isn't in the
	process table (which you cannot easily get at).  On some systems the
	u-page is directly readable and you can simply grab the stuff (this
	is true for Vaxes under some flavours of Unix.  On systems like
	Sun-3s where this page is not readable you have to use the other
	technique.

Letting another process grab the state info:
	There is a mystic system call called ptrace that allows a process to
	access the address space of another process (this includes reading and
	partial writing of the u-page).  The process being inspected has to
	make a call saying it is willing to be inspected and the process that
	does the inspecting gains a LOT of control over the other process
	The debuggers usually use this procedure and you should know what they
	are capable of.  Sun-3s add a nice feature to the ptrace interface that
	allows you to read whole blocks of memory and write them out again (the
	previous interface that I've seen only allowed read/write of a single
	word).


Some other hints:
You will probably have to patch the standard libraries quite a bit to get
migration working since I know of know other way to have any access to the
files opened by a process (without delving into the kernel, I am assuming
that you want migration without kernel access).
Most other status information for a process can be retained without kernel
access (or even superuser access).

It might be useful to leave a stub process behind on the original host to
perform the IO for the migrated process.  Doing this will greatly ease the
handling of file/device descriptors without remember lots of stuff about
how they were opened and/or created.

When I did a process migrator, the standard interfaces to ALL systems calls
were patched and a flag was added to every process to indicate if it was
running native or migrated (added just after the standard startup code
in the libraries).  System calls for migrated processes were propagated
back to the original host and performed if necessary.

[
	The migrator which I base my comments on, was written by two
	honours students as a project in 1988.  Really, it was only a
	remote fork primative that was intended to be a transparent
	replacement for the standard fork() system call.  We implemented
	the thing on a micro-vax running BSD4.3.  It was one of the most
	complete packages I've yet encountered for Unix.  Remote processes
	could exec other processes and it worked!  Remote processes could
	not call fork() or rfork() and expect to work unless they were
	specially written to co-exist with the package.  All file
	descriptors and resource limits were preserved.  The package
	required programs to be re-linked with a new version of the
	standard library and then remote forks were permitted.  No usage
	was made of super-user powers at all (how that for neat :-).
	We didn't even use the ptrace system call.

	The reason we used the Vax and not a Sun was that the sun's didn't
	let a process read its own u-page stuff.  We let the process dump
	itself before migration.

	That is about all I can remember about it at the moment.
]





							Pauli
seeya

Paul Dale               | Internet/CSnet:            grue at batserver.cs.uq.oz.au
Dept of Computer Science| Bitnet:       grue%batserver.cs.uq.oz.au at uunet.uu.net
Uni of Qld              | JANET:           grue%batserver.cs.uq.oz.au at uk.ac.ukc
Australia, 4072         | EAN:                          grue at batserver.cs.uq.oz
                        | UUCP:           uunet!munnari!batserver.cs.uq.oz!grue
f4e6g4Qh4++             | JUNET:                     grue at batserver.cs.uq.oz.au
--