Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!think!rlk
From: rlk@think.COM (Robert Krawitz)
Newsgroups: comp.arch,comp.unix.wizards,comp.os.minix
Subject: Re: Free Software Foundation (was: Re: Mach, the new standard?)
Message-ID: <8490@think.UUCP>
Date: Wed, 16-Sep-87 12:33:23 EDT
Article-I.D.: think.8490
Posted: Wed Sep 16 12:33:23 1987
Date-Received: Sat, 19-Sep-87 00:41:01 EDT
Sender: news@think.UUCP
Reply-To: rlk@THINK.COM
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 89
Xref: mnetor comp.arch:2198 comp.unix.wizards:4274 comp.os.minix:1655

In article <7320@felix.UUCP> preston@felix.UUCP (Preston Bannister) writes:
]In article <87@sdeggo.UUCP> dave@sdeggo.UUCP (David L. Smith) writes:
]>BSD 4.3 would run just fine on an 80386 and it does run just fine on 68000's
]>and 68020, so there is no reason that GNU wouldn't.  "Personal computers 
]>available today" are available based on those chips, and that is where the 
]>market is heading.  
[...386 boxen and Mac II w/68851]
]That leaves out the vast majority of personal computers.

These days.  How about t[gettimeofday()+2yrs]?  That, after all, is
what the FSF is heading for.

]>With some work, 
]...
]>Minix could be changed to be BSD compatible.  
]
]I would think that the best long-term goal would be to make Minix as
]close to Posnix compatible as possible.

Minix was designed as a teaching system, not as a production system.
It would take lots of hacking to hammer it into shape.  For that
matter, so would GNU, I suppose, but it's starting from a premise that
strikes me as more amenable to a production machine.

]I think what we should _really_ be thinking about is how to make Minix
]match the availible machines more closely.  One thing about Unix that
]has always bugged me is the fork() primitive.  The fork primitive
]_assumes_ that you can make an _exact_ copy of a running process.
]That's rather difficult (expensive, ugly...) on a machine that doesn't
]support the right flavor of virtual memory.  It also ties the process
]abstraction and the virtual address space abstraction together (i.e.
]you can't have more than one process in the same address space).

Hmm...seems to me that you could implement fork() on an 8086, if you
used a small memory model and programs cooperated (didn't play with
the segment registers).  The PDP11 didn't have virtual memory either,
if my memory serves me.  To run multiple processes concurrently you
need memory management, but not necessarily virtual memory.  To fork,
you need some way of creating distinct address spaces.  You certainly
don't need virtual memory.

Since Minix runs on an 8086 just fine, and that's the weakest
processor that anyone has any interest in running multiprocess things
on, I don't see why this is a problem.

]Most uses of fork() are immediately followed by an exec() call.  Why
 ^^^^
]else do you think the BSD people came up with vfork()?  

For these cases.
							 
							 A direct "start
]program in a seperate process" call would accomplish the same effect
]and would be easily implementable on machines without hardware support
]for (the right flavor of) virtual memory.  

That already exists in BSD and probably in SysV, but as a library call
implemented in terms of fork() (or vfork()) and exec().  In fact,
Kernighan & Pike give an example of a rewritten system() useful for
special purposes (it's been a while since I read it, so forgive me for
no page or context reference).

]I'd rather see primitives like "start process in same address space",
]"start process in new address space", and "start program in new
]address space".  (Perhaps this could be orthogonalized by combining
]primitives for program-loading, process creation, and address space
]creation).  I suspect with a little thought, the primitives could be
]implemented _efficiently_ on a much wider range of machines.

Vfork in BSD is implemented reasonably efficiently (compared to fork,
at least), and it's hard to see why it couldn't be implemented
correctly on a non-VM machine.  Remember that when you do a vfork, the
child process shares the address space of the parent (indeed, the
parent goes to sleep until the child exits or forks).  This may be
what you're looking for.

But remember, fork() is useful by itself in many circumstances, such
as daemons that handle more than one input or output channel
(sendmail, inetd, etc.).

Personally, I'd rather see machines that have facilities powerful
enough to run big, powerful software like GNU and emacs.  I don't care
for software that's been held back because of {IBM,Microsoft,Intel}
brain damage.  Just because a large blue company and clones sell more
computers than anyone else doesn't mean that it's the way to go.  I'm
more interested in 68020/68030, 80386 or 80486 whenever that happens
because the life cycle will probably be a lot longer.

Robert^Z