Path: usenet.ee.pdx.edu!cs.uoregon.edu!sgiblab!swrinde!howland.reston.ans.net!E
U.net!Germany.EU.net!netmbx.de!sietec.de!news!jh
From: jh@poseidon.sietec.de (Jochen Roger Hayek)
Newsgroups: gnu.misc.discuss
Subject: HURD & migration facilities
Date: 24 Oct 1994 15:12:34 GMT
Organization: Sietec Systemtechnik, Berlin
Lines: 16
Distribution: world
Message-ID: <JH.94Oct24161234@poseidon.sietec.de>
Reply-To: Jochen.Roger.Hayek@sietec.de
NNTP-Posting-Host: sunmiet3.sietec.de

I read an article from acm's sigops vol. 28, number 4 this weekend, having the 
title:

	a brief survey of systems providing
	process or object migration facilities
	by Mark Nuttall

I found it very instructive.

I think process / object migration should be considered for HURD, too,
and it's important to look at that before supporting / emulating
UNIX's fork and inherited open file descriptors,
because those features might get contradictory if not carefully designed.

Regards esp. to the HURD folks

JH

Path: usenet.ee.pdx.edu!cs.uoregon.edu!sgiblab!spool.mu.edu!bloom-beacon.mit.ed
u!ai-lab!life.ai.mit.edu!mib
From: mib@churchy.gnu.ai.mit.edu (Michael I Bushnell)
Newsgroups: gnu.misc.discuss
Subject: Re: HURD & migration facilities
Date: 24 Oct 1994 18:10:25 GMT
Organization: Free Software Foundation, Cambridge, MA
Lines: 27
Distribution: world
Message-ID: <MIB.94Oct24141025@churchy.gnu.ai.mit.edu>
References: <JH.94Oct24161234@poseidon.sietec.de>
NNTP-Posting-Host: churchy.gnu.ai.mit.edu
In-reply-to: jh@poseidon.sietec.de's message of 24 Oct 1994 15:12:34
	GMT

In article <JH.94Oct24161234@poseidon.sietec.de> jh@poseidon.sietec.de (Jochen 
Roger Hayek) writes:

   I think process / object migration should be considered for HURD, too,
   and it's important to look at that before supporting / emulating
   UNIX's fork and inherited open file descriptors,
   because those features might get contradictory if not carefully designed.

Process migration is not a problem for the Hurd--it's a problem for
Mach.  If a Mach task can be correctly migrated, then there is no
problem.

However, I want to do more than that with the Hurd; I want to have a
collection of machines (I think I'll call it a ``Collective'') appear
as a single machine.  (Shades of amoeba here.)

This is the first (and harder) task--making a single global space of
pids, etc.  

The second (and easier) task is migration.

	-mib
--
+1 617 623 3248 (H)         |  		En arche en ho logos, 
+1 617 253 8568 (W)        -+- 		  kai ho logos en pros ton theon,
1105 Broadway               |  		  kai theos en ho logos.
Somerville, MA 02144        |  		Kai ho logos sarx egeneto,
mib@gnu.ai.mit.edu          |  		  kai eskenosen en hemin.

Newsgroups: gnu.misc.discuss
Path: usenet.ee.pdx.edu!cs.uoregon.edu!reuter.cse.ogi.edu!psgrain!agora!hermes.
rdrop.com!erich
From: erich@uruk.org (Erich Boleyn)
Subject: Re: HURD & migration facilities
Sender: news@agora.rdrop.com (David Greenman)
Nntp-Posting-Host: uruk.org
Organization: RainDrop Laboratories
Message-ID: <ERICH.94Oct29093537@uruk.org>
References: <JH.94Oct24161234@poseidon.sietec.de>
	<MIB.94Oct24141025@churchy.gnu.ai.mit.edu>
In-Reply-To: mib@churchy.gnu.ai.mit.edu's message of 24 Oct 1994 18:10:25 GMT
Date: Sat, 29 Oct 1994 16:35:37 GMT
Lines: 50


In article <MIB.94Oct24141025@churchy.gnu.ai.mit.edu> mib@churchy.gnu.ai.mit.ed
u (Michael I Bushnell) writes:

   Process migration is not a problem for the Hurd--it's a problem for
   Mach.  If a Mach task can be correctly migrated, then there is no
   problem.

   However, I want to do more than that with the Hurd; I want to have a
   collection of machines (I think I'll call it a ``Collective'') appear
   as a single machine.  (Shades of amoeba here.)

Great!  (I think we talked about this before...)

   This is the first (and harder) task--making a single global space of
   pids, etc.  

This point seems somewhat questionable.  Maybe we're thinking about
the same idea in the long run, but I don't think that migrating
data about the whole system around would be very useful...
I mean, you still want a very large collective to work, though it
could well get bogged down by the details of huge amounts of info.

I think a more optimal (and more practical) approach would be to:

Create a model of a "user context" that keeps track across multiple
machines what resources and programs a user is working with.

There would also be publically known "services" that would be advertised.
Note that "advertising" is a specific activity that is usually not
performed, unless one desires to do so.

Anything else is really of little or no concern except to a local group of
machines (for resource-balancing issues).  So machines would automatically
keep in touch with other nearby machines, but it would be modulated by
distance.

The big question is this (and for that matter, other models) is that
of authentication in some kind of reasonably reliable manner.

   The second (and easier) task is migration.

Agreed.

Erich

--
Erich Stefan Boleyn                 \     Mad Genius wanna-be, CyberMuffin
Mathematician, Software Engineer       \      slavering computer nerd
Internet E-mail:   <erich@uruk.org>      \ "Forget Artificial Intelligence,
Motto: "I'll live forever or die trying" \      I want the real thing!"