tnk@athena.cs.wayne.edu (Tahir N. Khan) (12/13/90)
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.
Please reply either to my email address or post to the
newsgroup.
Thanks in advance,
Tahir N. Khan
Dept. of Computer Science
Wayne State University
Detriot, MI
Email : tnk@cs.wayne.edu
grue@batserver.cs.uq.oz.au (Frobozz) (12/14/90)
In <1990Dec12.181012.17399@cs.wayne.edu> tnk@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@batserver.cs.uq.oz.au Dept of Computer Science| Bitnet: grue%batserver.cs.uq.oz.au@uunet.uu.net Uni of Qld | JANET: grue%batserver.cs.uq.oz.au@uk.ac.ukc Australia, 4072 | EAN: grue@batserver.cs.uq.oz | UUCP: uunet!munnari!batserver.cs.uq.oz!grue f4e6g4Qh4++ | JUNET: grue@batserver.cs.uq.oz.au --
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/14/90)
In article <1990Dec12.181012.17399@cs.wayne.edu> tnk@cs.wayne.edu.UUCP () 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. You could try using pmckpt, the poor man's checkpointer. pmckpt is a cooperative checkpointer, which means that you have to add information to your program to use it. It's hellishly portable---several people have even reported pmckpt working under System V variants. I have successfully used pmckpt to transfer a running program and its files between two Suns. pmckpt is available via anonymous ftp to stealth.acf.nyu.edu as pub/flat/pm-pmckpt-0.95. I'll be releasing a new version soon, with better preamble support and some options for saving BSD-specific u area information. ---Dan