rheffel@cs2.wsu.edu (05/31/89)
I will now add my 2 bits about the direction of MINIX. MINIX is a good tool for teaching and learning about OS. However, not only do you have to keep up with the market trend in hardware ie 286/386 machines, it is also imperative to teach the principles of protected mode hardware and its influence on OS. I intend to upgrade to 286 MINIX and run it from now on. Nevertheless, I do agree with another MINIX devotee that MINIX needs a C compiler that produces large model programs. That is it. Rich Heffel (rheffel@cs2.wsu.edu)
rbthomas@athos.rutgers.edu (Rick Thomas) (06/07/89)
First)
Minix is clearly (as lots of people have said) heading in two different
directions: The "teaching" version that runs on cheap XT clones, and
supports only "small" programs; and the "hacker" version that runs on
32 bit hardware with multiple Megabytes of RAM and big hard disks and
has a compiler that supports big programs. (What people with 80286
based machines will do is problematical.)
Second)
Andy has agreed to support the "teaching" version as an adjunct to
keeping his book up to date. (He may not have thought of it in this
way, but for the purposes of this message, that is what it amounts
to.) He has announced his intention to bring the teaching version up
(-: if "up" is the right word... :-) to POSIX compliance, and to keep
it small in so doing. This will inevitably be accomplished at the
expense of support for the "hacker" version.
Third)
There is (at present) no single person with an announced intention of
supporting the "hacker" version of Minix to the extent of maintaining
an "authorized" set of source code for it. Many people have made
tremendous contributions to the effort, but there exists no
"authoritative" collection of contributions that one can retrieve (over
the net, by e-mail, by paper mail, or any other way) with a
comprehensive index that allows one to pick and choose intelligently
amongst the options. (The "bugs" archives are great (and we owe the
maintainers a vote of thanks!) as far as they go, but they are much too
large to be fully useful given the rather limited indexing technology
that is available.) We need someone whom we all trust as much as we
trust Andy, and who is as dedicated to maintaining the purity of the
"hacker" version as Andy is to the "teaching" version.
Finally)
There are lots of things that would be nice to have in the "hacker"
version of Minix (I have my own wish list: Large model compiler (would
GCC fit this bill?), protected mode support, POSIX compliance,
job-control (though I don't like the BSD way of doing it -- I
personally think the System V way -- with the "shl" program providing
multiple virtual terminals -- sort of a poor man's window system -- is
cleaner -- but it needs a couple of features from BSD to round it out
-- perhaps the POSIX people have a workable compromise), graphics
support, and so on... We can debate the merits til the cows come home)
but the first thing it needs is a "champion".
Any volunteers?
--
Rick Thomas
uucp: {ames, cbosgd, harvard, moss, seismo}!rutgers!caip.rutgers.edu!rbthomas
arpa: rbthomas@CAIP.RUTGERS.EDUwbeebe@rtmvax.UUCP (Bill Beebe) (06/07/89)
This message is empty.
jca@pnet01.cts.com (John C. Archambeau) (06/09/89)
The problem with a large model compiler is how are large model programs going
to be maintained by Minix? It's not the compiler that's going to be the
problem, it's juggling around the code and data segments of the program by the
kernel. The fact that the kernel keeps track of one code segment and one data
segment under the current Minix makes live hellishly simple. All the compiler
does is generate code, the linker will arrange the segments in some order that
makes it manageable under Minix. So before you people start chanting 'large
model' compiler, I want to hear the following;
1. How are the segment registers going to be maintained?
2. Are there going to be memory models (ala MesS-DOS C), and if so what
are they?
3. How will pointer types be handled? This is a big problem under
MesS-DOS C compilers with your near, far, and huge pointers. And will
each memory model have a default pointer size?
I agree that a large model compiler is highly desireable, but how is the
kernel going to handle large model programs? When this question is answered,
then a large model compiler will be a reality, but you can't really do a thing
until that question is answered. I also have it on fairly good authority that
GCC can not be ported over to 80x86 (where x < 3) machines easily. Some have
considered the thought to be more trouble than its worth. The problem is the
64K segments, with large model programs, they get in the way. I believe that
the 'real' versions of 80x86 UNIX handle the large model problem just by
making shared code segments, which is more of a hack than a real answer to the
problem at hand. I have no qualms about writing a C compiler myself for
Minix, but to achieve this large model business, some of us will have to
decide exactly how 8086/80286 Minix will handle large model programs. Memory
and process management for multiple code and data segments for a single
process won't be fun, but I'm pretty sure it is doable, and if done correctly
it might even run quite nicely. Once all of these problems have been handled,
a bare bones ANSI C compiler with simple peephole optimization won't be far
off. The lexer and parser for shareware/PD ANSI C compilers can be pulled for
the new Minix C and the only thing that needs to be written is the back end of
the compiler. Later, if any of us have any brain cells or sanity left, more
optimization can be done to produce nice tight code.
/*--------------------------------------------------------------------------*
* That's not an operating system, this is an operating system!
*--------------------------------------------------------------------------*
* UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!jca
* APRA: crash!pnet01!jca@nosc.mil
* INET: jca@pnet01.cts.com
*--------------------------------------------------------------------------*/
#include <disclaimer.h>EPRF%SNYCENVM.BITNET@cornellc.cit.cornell.edu (Peter Flass) (06/12/89)
-- How to handle "large model" programs in 8086 systems --
My vote, in the interests of keeping things simple, would be to have
MINIX-PC continue to keep track of one-each I and D "segments", but allow
the segments to be arbitrarily large. The compiler should be responsible
for managing pointers to map the Minix segment to the 8086 segment.
I don't see a need, in general for sophisticated memory management in
Minix, but the operating system should keep out of an application's way
as much as possible. One program should be able to use all free memory
if necessary.
- Pete
+---------------------------------------------------------------------------+
| |
| PETER FLASS BITNET: EPRF@SNYCENVM (PREFERRED) |
| DIRECTOR OF COMPUTING SERVICES INTERNET: ESCFLASS@UBVM.CC.BUFFALO.EDU |
| SUNY EMPIRE STATE COLLEGE AT&TNET: (518)587-2100 X350 |
| 2 UNION AVENUE |
| SARATOGA SPRINGS NY 12866 "THIS SPACE FOR RENT" |
| |
+---------------------------------------------------------------------------+goedhart@utrcu1.UUCP (Goedhart) (06/15/89)
Hi, I think MINIX is great, and I want to thank dr. Tanenbaum for having created it. It is used at our school as a teaching tool. But, I don't think people should use it as a 'cheap UNIX'. People who want such an operating system should look elsewhere. Now the protected mode bit. It would be great to have a MINIX which uses the protected mode of a 80[234]86. Operating systems are often writtin on machines with such capabilities, and should therefore be teached to students. Besides, since there are almost no books dealing about protected mode, I think Andy might fill this gap. The argument that students don't have the money to buy hardware with memory protection is not entirely true anymore. Prices of AT class machines are falling, and therefore MINIX should be ready to run on those systems when they are in reach of a large amount of students. I know a few students who own a 80286 machine, and a few who own a 80386 machine. And I know a few who plan to buy such hardware in the near future. Soooo, think about it will you? Peter (I am momentarely using the account of a friend) -- Who would believe the word of a man speaking double Dutch. Well I am a Dutchman (honestly!).
root@cca.ucsf.edu (Systems Staff) (06/15/89)
In article <251@utrcu1.UUCP>, goedhart@utrcu1.UUCP (Goedhart) writes: > > The argument that students don't have the money to buy hardware with > memory protection is not entirely true anymore. Prices of AT class > machines are falling, and therefore MINIX should be ready to run on > those systems when they are in reach of a large amount of students. > When schools rushed out to buy the original PCs many were buying them at prices like $2500 - $3000. And then they had to spend like $500 for a full memory quota. Etc. Etc. Now the going price for the Intel 80386 upgrade boards for those PCs is $599 (singles, probably less in batches) including a megabyte of memory. Many places advertise this price and I bought one so I know the price is real. There is something wrong with the argument that the basic PC is all schools can afford; if they are sticking to basic PCs for CS students in an OS lab they are seriously abusing these students with obsolete equipment. Just for fun, I flipped open the current issue of Computer Currents magazine to find this advertised: 20 MHz 386 system 1 MB ram expandable to 8 MB on board 1.2MB floppy drive 1:1 interleave controller 66 MB hard disk (25 ms access) 2 serial, 1 parallel, 1 game port 101 Keytronics KBD 220W power supply Real Time Clock/CMOS memory w/Battery back up Socket for 80387 Supports MS DOS, OS|2, Unix, Xenix, ... 14" Monochrome monitor & card Price $1860 And you could probably shave this with a smaller disk, save $40 by taking the 12" monitor, get a quantity discount, etc. A few pages before there is a cheaper machine: 16 MHz 386sx 1 MB ram expandable to 8 MB on board 1.2 MB Teac Floppy 42 MB hard disk Mono card & monitor This one is $1599. And the 80486 based machines aren't even here to further depress the prices on the current models. There seems to be little point in doing any substantial new work for PC family systems that isn't aimed in this direction. Thos Sumner (thos@cca.ucsf.edu) BITNET: thos@ucsfcca (The I.G.) (...ucbvax!ucsfcgl!cca.ucsf!thos) U.S. Mail: Thos Sumner, Computer Center, Rm U-76, UCSF San Francisco, CA 94143-0704 USA OS|2 -- an Operating System for puppets. #include <disclaimer.std>
rossj@cognos.UUCP (Ross Judson) (06/23/89)
Just to add a little more fuel to the fire, our school of comp sci has dumped a pile of 8088 based machine on other departments and on first year courses, and gone AT. We have (I think) 70 or so ATs for course use. Right now the third year operating systems course dissects PC-Xinu. I think the course could be modified to deal with protected-mode MINIX. Clearly, the future trend is towards memory managed hardware. Students will be overwhelmed no matter what course they take; it is better to make it as realistic as possible. -- uucp - uunet!mitel!sce!cognos!rossj |people hate the generator arpa/internet - rossj%cognos.uucp@uunet.uu.net |but love to light up the sky