Date: Fri, 27 Oct 1995 10:01:29 +48000 From: Gavin Lim <gavin@linux1.dlsu.edu.ph> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: hackers@freefall.freebsd.org Subject: Re: your mail Message-ID: <Pine.3.89.9510270946.A5969-0100000@ccslinux.dlsu.edu.ph> In-Reply-To: <27312.814627027@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 25 Oct 1995, Jordan K. Hubbard wrote: > > 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!" :) ] Sorry guys, who else could we turn to? > > 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! We've made several assumptions regarding the processes that would be migratable. 1. The processes will not have any files explicitly opened. 2. The processes do not use any means of IPC except through signals. 3. The processes are background processes and are not associated with any controlling terminal. (although we figure that we could have a simple rprintf() call to make a printf() RPC call on the source host.) 4. We assume a homogeneous system of 486 PCs with FreeBSD 2.0.5 on them. To use the process migration facility, we would be adding a system call through a LKM. This system call looks like this. int migrate(pid, destination_host); where pid is the ID of the process to be migrated, and destination host is the address of the destination processor. We figure that we are to make variations of the following calls: 1. fork() 2. wait() 3. kill() 4. getpid() 5. getppid() Only processes which use these variations are migratable. We are to make the process migration facility without modifying FreeBSD. We already have an idea how to do it. It has been done before, and was implemented on 4.2BSD. They did it without any rearchitecturing. Maybe these would make things clearer and easier. We already have a general design, but we would have to know the details of FreeBSD to implement it. That's why we're turning to you guys. ============================================================================== Gavin Lim Gavin@linux1.dlsu.edu.ph ==============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.3.89.9510270946.A5969-0100000>