Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!ames!elroy!mahendo!jplgodo!wlbr!scgvaxd!trwrb!felix!preston From: preston@felix.UUCP (Preston Bannister) Newsgroups: comp.arch,comp.unix.wizards,comp.os.minix Subject: Re: Free Software Foundation (was: Re: Mach, the new standard?) Message-ID: <7320@felix.UUCP> Date: Mon, 14-Sep-87 15:17:48 EDT Article-I.D.: felix.7320 Posted: Mon Sep 14 15:17:48 1987 Date-Received: Fri, 18-Sep-87 07:05:37 EDT References: <1665@ncr-sd.SanDiego.NCR.COM> <8381@utzoo.UUCP> <797@Pescadero.ARPA> <692@sugar.UUCP> <87@sdeggo.UUCP> Sender: daemon@felix.UUCP Reply-To: preston@felix.UUCP (Preston Bannister) Organization: FileNet Corp., Costa Mesa, CA Lines: 68 Xref: mnetor comp.arch:2193 comp.unix.wizards:4268 comp.os.minix:1653 In article <87@sdeggo.UUCP> dave@sdeggo.UUCP (David L. Smith) writes: >It's kind of like all the people who have taken Pascal ... >and wanted to try and develop real software in it. It's possible, but it >ain't pleasant. Please, no language R-wars. I've used C, Modula-2, Pascal and Lisp quite a lot at different times. None of them is universally preferable to the other. And yes, I _have_ developed "real" software in Pascal. >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. Close but not quite. The 68000, 68010 and 68020 cannot support demand paged virtual memory without an MMU. The (original) 68000 has a basic flaw that makes implementing virtual memory ugly even _with_ an MMU. The only easily availible (i.e. low cost) machine with a suitable support for demand paged virtual memory is the 80386-based PC family. The next closest candidate is the Mac II, which will have a reasonable MMU sometime soon (when Motorola gets it's new MMU chip out the door). That leaves out the vast majority of personal computers. >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. >The first >task, though is to port it to a 68000 (with a good memory manager) or an >80386 and get around the 64K task size limit. The rest could be added in >slowly. The add something constructive to this discussion... :-) 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). Most uses of fork() are immediately followed by an exec() call. Why else do you think the BSD people came up with vfork()? 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. 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. -- Preston L. Bannister USENET : ucbvax!trwrb!felix!preston BIX : plb CompuServe : 71350,3505 GEnie : p.bannister