Merge branch 'master' into external_pager_mechanism

Conflicts:
	microkernel/mach/external_pager_mechanism.mdwn

1 files changed, 141 insertions, 0 deletions

diff --git a/unsorted/hurd-migr b/unsorted/hurd-migr
new file mode 100644
index 00000000..ce36c86c
--- /dev/null
+++ b/unsorted/hurd-migr
@@ -0,0 +1,141 @@
+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!"