1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
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!"
|
