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!"