Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!ames!ptsfa!well!ewhac
From: ewhac@well.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: Ami - MINIX problem for gurus
Message-ID: <4478@well.UUCP>
Date: Wed, 18-Nov-87 19:30:28 EST
Article-I.D.: well.4478
Posted: Wed Nov 18 19:30:28 1987
Date-Received: Sat, 21-Nov-87 08:42:40 EST
References: <8711180347.AA10717@jade.berkeley.edu>
Reply-To: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Organization: Whole Earth 'Lectronic Link
Lines: 49

In article <8711180347.AA10717@jade.berkeley.edu> JPARR@UREGINA1.BITNET (John Parr) writes:
>     I ran across a technical difficulty when trying to port MINIX to the
>Amiga.  How the heck can you do a fork?

	You don't.

>     The problem is this.  When a process is first loaded in from disk, it
>is nicely relocateable up until the time it runs.  Once it runs, however,
>any pointers that it uses will be absolute addresses.  When copying the
>parent over to the child, all pointers will still point to the parents
>data area.  Amiga DOS must run up against similar problems, what does it do?

	It avoids it.  It never forks.  It merely loads a new copy of the
program in question and runs it.

>     Right now I can think of only two solutions.  The first is to have a
>"running" area in memory.  Then whenever a process was scheduled, its image
>would have to be copied into this area.  When finished, it would be recopied
>back to its own area.  Obviously, this is not the best solution, although
>it would work.  (maybe?)

	Congratulations.  You've just decribed Dual's first-generation UNIX
memory management scheme on the 68000 before MMU's existed.  It worked
great, but was.............s...............l...........o..........w.......

>     The second solution would be to remove the ability to fork altogether
>and have a single fork_exec call to spawn new processes.  As soon as I do
>this, MINIX is no longer very much like MINIX, so this isn't really too
>ideal either.  Suggestions?

	You have two choices:  One is to remember where the program came
from off mass storage, and when the user fork()s, you merely load in a new
copy of the program and run it.  Not elegant.

	The other is to impose a rule whereby no program is permitted to
store data or modify its code segment while running.  Then, when initially
loading the program, you seperate the data and code segments.  At startup, you
make a copy of the data segment, and point the program at the copy.  When
the program fork()s, you use the same copy of the code (shared text?), make
a new copy of the data segment, and point the fork()ed process at the fresh
data copy.  More elegant, but subject to pitfalls.

	Dunno how well either of these would work.

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape	ihnp4!ptsfa -\
 \_ -_		Recumbent Bikes:	      dual ---> !{well,unicom}!ewhac
O----^o	      The Only Way To Fly.	      hplabs / (pronounced "AE-wack")
"Work FOR?  I don't work FOR anybody!  I'm just having fun."  -- The Doctor