Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!sun!pitstop!sundc!seismo!uunet!munnari!basser!steve
From: steve@basser.oz (Stephen Russell)
Newsgroups: comp.os.minix
Subject: Re: Why the 8086 architecture is wonderful :-)
Message-ID: <1845@basser.oz>
Date: 14 Mar 89 04:12:56 GMT
References: <13428@ncoast.ORG> <85126@felix.UUCP> <4566@cs.Buffalo.EDU>
Organization: Dept of Comp Sci, Uni of Sydney, Australia
Lines: 42

In article <4566@cs.Buffalo.EDU> ugkamins@sunybcs.UUCP (John Kaminski) writes:

>
>It is my opinion that fork() assumes nothing about anything.

Your own example shows that fork() _DOES_ assume certain properties of the
underlying architecture.

> [Example of problems with an OS9 application due to lack of separate
>  fork()/exec() calls deleted]

Ask yourself why the OS9 designers left out the UNIX-style fork(). The
answer, of course, is that fork() is difficult/expensive to perform without
appropriate MMU hardware. The 6809/68000 machines either lack any MMU, or
suffer from the lack of a standard (at least until the very late introduction
of the 68881 (?) PMMU for the 68020 series).

Why is the MMU important? After a fork() the child's data segment will
obviously occupy different physical memory addresses than the parent's.
However, the program text contains addresses fixed by the linker
for static/extern data, and the data contain the addresses of auto or
malloc'd variables. Without an MMU to translate these addresses to the
child's new data region, all memory refs from the child will still refer
to the parent data. This breaks the UNIX fork() semantics.

Of course, we could postulate restrictions on the semantics of fork()
so that this is not a problem. For example,
	
	- the child cannot access any data that existed before the fork(),
	or if it does, it may incur the wrath of its parent.

	- the child _can_ access data that it allocates itself, using malloc
	or by calling a function, thus growing its stack.

	- the child cannot return from the function that called fork()

	- etc.

These restrictions don't exist in UNIX, so they should not exist in Minix.
Fortunately, the 8x86 series allow separate data segments, thanks to the
DS register. While the architecture may be ugly in other ways, it does
allow efficient fork() implementation.