Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!rpi!crdgw1!ge-dab!peora!rtmvax!bilver!wbeebe From: wbeebe@bilver.UUCP (bill beebe) Newsgroups: comp.os.minix Subject: Re: Bruce Evans' opus Message-ID: <216@bilver.UUCP> Date: 28 May 89 22:26:24 GMT References: <2570@ast.cs.vu.nl> Reply-To: wbeebe@bilver.UUCP (bill beebe) Organization: W. J. Vermillion, Winter Park, FL Lines: 61 In article <2570@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > >Bruce Evans has clearly done a great deal of high quality work in his recent >giant posting and I am sure many people are interested in it. Furthermore, >I hate to be a party pooper, but... > >According to P-H's sales figures, the PC version of MINIX is still outselling >the AT version by a wide margin. This means that there are a lot of 8088s >still out there. Consequently, I am going to base V2.x on 1.4a, not on Bruce's [some stuff deleted] >This means that if you convert to Bruce's system now, you may have trouble >converting to 2.x (POSIX-based) later. It is clearly up to you which way you >go, but at least you should be aware that there is a fork in the road here. > >The long term plan for MINIX is to wait until not only the 8088, but the 286 >has also vanished, and make MINIX 3.x (probably in 4 or 5 years) entirely >a 386/486/585/686/786 based system, assuming these are all architecturally [more stuff deleted] I hate to be a party pooper too, but I find Bruce Evan's postings what PC Minix needs to move into the larger world of the 386. I find it interesting you base your figures on P-H's sales figures, without qualifying who is really buying Minix. It would be interesting to see what systems at major universities are running Minix. I have found that the majority of systems in U.S. universities are donated ATs, with the switch to 386 AT architectured machines. And we can roundly curse the "dwarf segments" on the 80286 under protected mode, but there is something to be said about 80286 PM code; it run's with little or no modification on 80386 machines. One other thing you need to think about, Mr. Tanenbaum, and I'll draw a picture to help illustrate my point. +-------------------+---+---+---+---+----------------+ | BASE 31...24 |23 |22 |21 |20 | LIMIT 19...16 | | |G |X |O |AVL| | +-------------------+---+---+---+---+----------------+ It's a crude picture of the upper 16 bits of the 80386 descriptor quad word. The high 16 bits were zero in the 80286, but in the 80386 we have four more bits in the limit field and eight more in the base. If we lave the base alone, the segment limit is now 1 meg, not 64 K. Using the current AT Minix architecture, that means programs can span 2 megs; 1 meg for code and 1 meg for data. It also means that segments have a one byte granularity. Using the base and setting the granularity bit, we can have segment limits up to 4 gig with a granularity of 4K bytes. I find your reasoning why Bruce Evan's work will cause a split to be flawed and technically imcompetent. I support Evan's work and will do whatever I can to add to the existing body of PM Minix code. As a matter of perspective one of our local Minix group here in Orlando, Florida ,Jim Smith, has stated that he had the least number of problems and glitches patching his version of Minix with Evan's posting. It has been one of the easiest, if not the easiest. And Jim has faithfully installed every major posting that has appeared in the conference. Evan's work was merged with Minix 1.3 purchased from P-H, and is running on a 20 MHz 80386 machine with 4 megs of memory, an Adaptec RLL controller, and an ST277. The 80386 AT bios drive tables were patched so that Minix boots from the RLL drive with the standard AT wini code. The Adaptec is register compatible with the WD standard. I'm sorry for the tone of my message, but Minix is far larger than you apparently realize. I would strongly recommend you do more research and deeper thinking about Minix's future path.