Info-IBMPC@C.ISI.EDU.UUCP (01/24/87)
Info-IBMPC Digest Friday, January 23, 1987 Volume 6 : Issue 4
This Week's Editor: Billy Brackenridge
Today's Topics:
Minix Special Edition
----------------------------------------------------------------------
[I am reprinting the original article on Minix we published a few weeks
ago. Discussions on minix have been raging on usenet for the last few
weeks and now there is even a mailing list devoted to minix. INFO-IBMPC
doesn't limit its self to discussions of MS-DOS systems. Minix is welcome
here as well, but perhaps some of the more unix oriented mailing lists
are more appropriate. We will just see how things go. This looks like a
great product and should be a boon to anyone teaching or wanting to
learn more about operating systems. I hope Minix is a great success. It
deserves the support of the network community. -wab]
Date: 22 Dec 86 09:33:09 GMT
From: ast@bottercs.vu.nl (Andy Tanenbaum)
Subject: UNIX Clone With Source Code Available
Date: 22 Dec 86 09:33:07 GMT
Organization: VU Informatica, Amsterdam
I have recently finished rewriting UNIX from scratch. This system, called
MINIX, does not contain even a single line of AT&T code, so it can be
distributed with source code. It runs on the IBM PC, XT, and AT and
those clones that are 100% hardware compatible (not all, unfortunately).
To the average, unsophisticated user, using MINIX is indistinguishable
from using V7 UNIX. Experts will notice that some relatively less
commonly used programs and features are missing.
MINIX FEATURES:
- System call compatible with V7 UNIX (except for a couple of minor calls)
- Kernighan and Ritchie compatible C compiler is included
- Shell that is functionally identical to the Bourne shell is included
- Full multiprogramming (fork+exec; background jobs in shell: cc file.c & )
- Full screen editor vaguely inspired by emacs (modeless, autoinsert, etc.)
- Over 60 utilities (cat, cp, grep, ls, make, mount, sort, etc.)
- Over 100 library procedures (atoi, fork, malloc, stdio, strcmp, etc.)
- Supports a hard disk, but also works quite well with just floppies
- Contains programs to read and write MS-DOS diskettes
- Full operating system source code is included
- Source code for all the utilities (except C compiler) is included
- System will recompile itself (requires 640K and 2 floppies or 1 hard disk)
- C compiler source is available as a separate package
- Kernel organization radically different from UNIX and much more modular
- Software is not copy protected
Furthermore, I have written a 719 page book telling you everything
you ever wanted to know about operating systems in general and this
one in particular. The book contains the manual pages, an appendix
describing how to recompile the system from the sources supplied, a
full source code listing of the operating system (253 pages), and a
cross reference map.
The software is available in 4 packages (book is separate):
- Box of eight 360K diskettes for 640K IBM PCs (512K is sort of ok too)
- Box of eight 360K diskettes for 256K IBM PCs (no C compiler)
- Box of five 1.2M diskettes for the IBM PC-AT
- 9 track industry standard tape (1600 bpi, tar format)
All four distributions contain the full source code, about 54,000 lines,
(kernel + utilities, except the compiler), virtually all of it in C. The
source code for the C compiler is also available separately (as described
in the book). The C compiler is NOT based on pcc at all. It is based on
ACK (see Communications of the ACM, Sept. 1983, pp. 654-660). The following
programs are included, among others. Like the kernel, these have all been
rewritten from scratch by me, my students, people I paid to write them or in
a small number of cases, were donated by other people to whom I am grateful:
ar basename cat cc chmod chown cmp comm cp date dd df dosread echo
grep gres head kill ln login lpr ls make mkdir mkfs mknod mount mv
od passwd pr pwd rev rm rmdir roff sh shar size sleep sort split stty
su sum sync tail tar tee time touch tr true umount uniq update wc
The book and software are being sold by Prentice-Hall. They are NOT
public domain. However, the publisher does not object to people making a
limited number of copies of the software for noncommercial use. For
example professors may make copies of the software for their students.
Universities may exchange modified versions. You may make a few copies
for your friends etc. If you want to port the software to other CPUs and
sell it, you need permission from Prentice-Hall, but they will not be
unreasonable. To acquire the software, go to any bookstore and ask them
to order the book for you:
Title: Operating Systems: Design and Implementation
Author: Andrew S. Tanenbaum
Publisher: Prentice-Hall (Jan. 1987)
ISBN: 0-13-637406-9
In the book you will find a postcard that you can use to order the
software. Please don't ask me for the software. I have already spent
approximately 8000 hours over the past 5 years writing it; I don't want
to spend the next 5 years duplicating floppy disks. The book costs about
$35. The software is $79.95 per set, including the source code. I hope
most people will consider $79.95 for the binaries and sources of
something almost functionally equivalent to UNIX as being reasonable. I
know of no other software package where you get 54,000 lines of source
code for this price. As bugs are reported, I will send Prentice Hall new
disks, so that the version they sell will remain up to date. (This also
provides some incentive to buy rather than copy.)
For those of you going to USENIX or UNIFORUM in Washington, D.C.
January 20-23, Prentice-Hall will have a stand at the show where you can
play with the software. You can also buy the stuff there, but since the P-H
people drive to Washington in their own cars, they have a limited carrying
capacity and they are only taking 50 copies, so get there early the first day.
If anyone is interested, we could set up a newsgroup
comp.os.minix to discuss minix, report bug fixes, distribute updates
of individual files etc. This letter is being multiply posted to
several newsgroups. I propose that the initial discussion take place
in comp.sys.ibm.pc (subject: MINIX) to avoid having it spread all
over the place. Besides, the only other newsgroup I read is
mod.recipes. I don't think the moderator will go for floppy disk
with Hollandaise sauce.
Andy Tanenbaum, Vrije Universiteit, Amsterdam
(mail to minix@cs.vu.nl; if your machine doesn't know where nl is
[The Netherlands], try minix@vu44.uucp, but that will vanish soon)
------------------------------
From: ast@botter.cs.vu.nl (Andy Tanenbaum)
Subject: MINIX
Date: 10 Jan 87 22:33:17 GMT
Date-Received: 13 Jan 87 09:03:08 GMT
Organization: VU Informatica, Amsterdam
First, I would like to apologize if I over-crossposted. I haven't posted much
to the net before, so I may have done things wrong. I was under the impression
that if one sends to multiple groups it cross posts them in such a way that
each reader only gets the message once, even if the reader subscribes to all
of them. If I am wrong will somebody please tell me how to do it (by mail).
It is also possible that I messed up. Furthermore, we were having news and
mail problems at the time, which may have contributed. It was my intention
that a lot of people see it once, not that a few people see it many times.
As to being commercial, that's true I guess, but since I am supplying 50,000
lines of source code without copy protection for $79, and I don't mind a
limited amount of copying of the binary and source code, it is not in the same
league as normal PC software in terms of the owners zealously guarding both
binaries and sources. In fact, it is probably somewhat closer to the Free
Software Foundation's way of doing things (also copyrighted) than to Lotus.
I assumed (and judging by the response, probably correctly) that there would be
a fair amount of interest. Sorry if I offended people.
Maybe it would be best to set up comp.os.minix now. Will everyone who would
want to subscribe to it send me mail. If there is a sufficient number, I
will ask the local guru how one sets up a new group and try to avoid messing
that up too. I will cross post this to various groups, but just stick to
comp.sys.ibm.pc or comp.os.minix (depending on the reaction) in the future.
Several people have asked me questions whose answers may be of general
interest, so I will post them here.
Q1: Can you have multiple users on a PC?
A1: In theory yes. The terminal driver has an array indexed by terminal
number from 0 to some maximum. At present that maximum is 1, so you
have to change a constant and recompile the tty driver. Also, there
is no RS232 driver (the deadline had a race with RS232 and the deadline
won). Therefore such a driver has to be made, but it is quite simple.
Most of the hooks and handles you need are already there, for example,
when it is time to output a character on tty n, the driver calls a
function pointed to by tty_struct[n].tty_devstart, so each terminal
can have a different routine to actually output the character. In this
way you can mix various device types.
Q2: How compatible does a machine have to be to run MINIX?
A2: It needs a NEC uD765 chip as floppy disk controller, a Motorola 6845 as
video controller, etc. If the hard disk controller is nonstandard, the
hard disk won't work, but the rest will. Machines with different I/O
chips but try to hide this by presenting the same BIOS interface won't
work. About a dozen different clones have been tested. MINIX worked
without problems on 80% and failed on 20%.
Q3: Can you call assembler routines from the MINIX C compiler in order to
write drivers for new devices?
A3: Yes. The C compiler uses the standard UNIX calling convention of pushing
the parameters onto the stack in reverse order, so there is no problem
writing bits of a program in assembler. The assembly language accepted
by the MINIX assembler is identical to that of PC-IX, the "official" IBM
UNIX system for the PC. Assembly routines for reading and writing I/O
ports are present in the file kernel/klib88.s (port_in and port_out).
Q4: What do you mean it will sort of run on a 512K machine?
A4: It will boot fine and run ok with 512K, but since it doesn't swap, it
won't be possible to run a lot of background jobs without running out
of memory. Also, if you use make, you may discover that make + cc +
the various passes that get forked off may not fit in core at once, which
causes EXECs to fail and make to get an error return. This can be solved
by changing the amount of stack space allocated to the compiler passes
using the chmem utility. (chmem is functionally the same as in PC-IX,
which works the same way.) Reducing the stack allocated to compiler
passes means that some very large programs may not compile. With a 640K
system, files > 50K characters have compiled. With 512K, that limit may
be lower.
Andy Tanenbaum (minix@cs.vu.nl)
------------------------------
From: ast@botter.cs.vu.nl (Andy Tanenbaum)
Subject: MINIX - From the mouth of the horse
Date: 8 Jan 87 23:11:03 GMT
Organization: VU Informatica, Amsterdam
I have just learned of quite a discussion going on in comp.sys.atari about
porting MINIX to the Atari. For all I know a similar discussion is going on
in comp.sys.amiga and elsewhere. I am cross posting this to several groups
in case there are people there who are interested in porting MINIX to their
machine. If you missed the original note in mod.os.unix, I have just written
a UNIX clone that is available now with all the SOURCE CODE for $79.95 from
Prentice-Hall. There is also a book telling how it works inside.
I suggest that subsequent discussion go on in comp.sys.ibm.pc to avoid
scattering it all over the place. At the very least, crosspost comments to
comp.sys.ibm.pc under the subject MINIX. Later, we can set up comp.os.minix
if there is enough interest.
Read the comp.sys.atari group under the heading Forwarded for the last 2 weeks
to get the background for this note.
Although MINIX is copyright (not licensed), Prentice-Hall has agreed to permit
people to make a LIMITED number of copies for educational use, home study etc.
Posting the source code on the network (54K lines of C, kernel+utilities) is a
no no, but if each purchased copy doesn't generated more than say, 2 or 3
copies it is ok. While this is not public domain it is a lot better than Lotus,
Microsoft, Borland, and every other software company in the world's policy.
About the pricing. It is clearly not shareware, but by publishing the
source code on diskette, we are clearly not acting like AT&T either.
I had some discussion with people like Brian Kernighan (author of
the Software Tools package) and Doug Comer (author of Xinu, a little
embedded operating system for the LSI-11, although not really UNIX
like) and came to the following conclusion. I would like to see MINIX become
widespread, so the distribution mechanism is crucial. Having a major
publisher like Prentice-Hall advertise it, bring it to shows, send out
junk mail, etc. will get it a lot more attention than a note on the
net. Getting a commercial publisher like Prentice-Hall interested means
charging something. I think in the long run, this funny, copyrighted
but not real aggressive position we are taking will cause MINIX to become
widespread, new software to be made for it, etc. The GNU people are
upset because deep in their hearts they, too, know that people would rather
pay a reasonable price for good stuff than get empty promises for free.
Does anyone know how much GNU charges for its "free" software for the tape,
postage, handling etc? Berkeley generally charges something like $125
for its tapes, as I recall. If GNU also charges $125 for its "free" software
it seems to me that their moral indignation at Prentice-Hall's outrageous
$79.95 price is somewhat weakened. I mentioned MINIX in netnews last year
and I got quite a few reactions. I have also contacted lots of people for
various reasons. With two exceptions, everybody congratulated me and wished
me good luck. Some people, especially Martin Atkins, Charles Forsyth, and
Richard Gregg gave me a lot of help, for which I am grateful. Only two
people were really negative, almost bitter--both from the Free Software
Foundation (names withheld because I don't believe in character assassination
on a world-wide network). I am tempted to comment further, but I won't.
As to the port to the Atari/Amiga/etc as far as I see, there are no technical
problems with the MMU. The trouble is as follows. When you fork, the
child has to go somewhere else in memory than where the parent was.
Unfortunately, the child's stack contains absolute addresses, such as
the return from the fork routine. If the child runs somewhere other
than where the parent was, it will crash.
There are a couple of solutions, the simplest of which is this. When the
child is created, record in the process table where the parent was.
When it is time to run the child, just swap the parent and the child,
and actually run the child where it belongs. When the parent wants to
run, swap them again. Although this sounds horrendous, it is not at all
so bad. Swapping two 10K programs in memory might take 30 millisec.
MINIX programs are small. I am a strong believer in Small is Beautiful.
At the end of this note you will find the sizes of the MINIX utilities.
The only big ones are the compiler passes, cpp, cem, opt, cg, and asld.
Furthermore, 99.9% of the time, the child does an EXEC, at which point the
operating system can put the parent back where it belongs, and put the
new core image anywhere in memory. In practice, all this trick will
cost is about two copies of the forked core image, and it doesn't require
modifying the compiler. My experience with fragmentation is that it is not bad.
MINIX doesn't swap because one of the design goals was to have it run on CHEAP
hardware (meaning a 256K PC with 1 floppy disk) and floppies are not ideal as
swapping devices.
The MINIX memory management scheme is very simple, because the PC's hardware
is primitive. A core image consists of the text, the data, a gap, and then the
stack, growing downward. The stack and the data segments grow into the
gap. If they meet, BOOM! In practice, very few programs have wildly
growing stacks or data segments. I ran some statistics once, and for 90%
of the MINIX utilities, 2K stack is plenty. On the PC, the text is limited to
64K, and the data + stack is also limited to 64K. On a 68000, there would
be no need for such a limit. It comes from the 8088 architecture.
All you have to do is change a couple of constants in the memory manager.
The book is already out. You should be able to order it at any book store.
The title is Operating Systems: Design and Implementation. The software
will be out in three weeks. It went into production about three weeks ago,
and it takes about six weeks. Don't ask me why. Probably the same reason
as why it takes Prentice-Hall 18 months to produce a book from the finished
manuscript (unless you give them camera ready copy, as I do). If you want to
get the software (either on PC diskettes or 9 track tape), first order the book
and then send back the business reply card (software order form) in the book.
I would like to see a MINIX version for the Atari/Amiga/etc. The 68000 is
clearly much better than the 8088, but the PC has a lot of software going for
it. Maybe a tolerable UNIX clone might help the Atari/Amiga/etc in its fight
against the monster from 8088-land. A colleague of mine at Philips has
already started to port MINIX to the Atari. He is an absolutely top rate
programmer, but he is VERY busy, so he doesn't have much time. I think he
has already rewritten the MINIX assembly code (low level interrupt
handlers, etc) for the 68000. I will check with him one of these days; he
seems to be away right now. What I would like to find is someone who:
(1) knows the Atari (Amiga, Macintosh, etc) hardware well
(2) knows UNIX well on the outside and moderately on the inside
(3) has a substantial amount of free time
(4) has access to an IBM PC for testing things etc. (not essential, but helps)
Perhaps such a person could do the port with a little assistance from me.
Unfortunately I don't have much time either, as Prentice-Hall is bugging me to
revise a book on networks I wrote a million years ago.
The main things to do, other than the 68000 assembly code, are the device
drivers, all of which are in C, but of course are totally different for
the PC and Atari etc. The PC version doesn't use the BIOS at all, because the
stupid thing doesn't use interrupts. When you start a background job up
and then start up the editor in the foreground, calling the BIOS to read
a character would put the whole computer in a tiny loop sitting and waiting
for the keyboard to produce a character. MINIX supports the full UNIX
multiprogramming, so I had to write all the drivers from scratch (in C). I
suspect that the Atari BIOS isn't any better, although maybe we could use the
screen output BIOS.
And here we come back to the $79 again. If the person doing the port does a
good job, Prentice-Hall could sell the other version on diskettes, source code
and all, for the same $79 as the PC version. I have enough clout with P-H
that I think I could arrange that. Needless to say, the person doing the
port would be remunerated for his efforts, probably in the form of a royalty
on each disk set sold. The royalty is typically only a couple of dollars,
but that small amount is why capitalism works and socialism doesn't.
If anyone is interested, let me know. I don't think it will be that difficult,
but you have to plow through much of a very tightly written 719 page book and
understand a 12,000 line program before you can even start, so it will no doubt
be months of work. Also, debugging operating system code on a bare machine
even a relatively nice one like the 68000, will be a fair amount of work.
One other point is the compiler. The compiler is based on ACK, which is
described in Communications of the ACM, Sept. 1983, pp. 654-660. ACK is a big
system for writing compilers. It is being distributed by UniPress in Edison
NJ and Transmediair in Utrecht, Holland. It uses the old UNCOL idea of having
front ends that generate a common intermediate code and then back ends that
compile from that code to the target machine. At present we have front ends
for C, Pascal, Modula 2, Basic, Occam, and even a subset of Ada. There are back
ends for virtually every micro around, from the 6502 to the 68020. The ACK
software is owned by the university I teach at. UniPress pays them a royalty on
each copy they sell (academic price is $995 for a source tape containing 6
megabytes, although Modula 2 and Occam aren't on the tape yet). Our department
doesn't have much money, and we use the royalties to allow grad students to go
to conferences and the like. For these reasons the compiler kit is not part
of MINIX. Furthermore even the 8088 C compiler source by itself fills 4
diskettes. If the compiler source were in the MINIX distribution, that would
have meant raising the basic price to over $100, very much against my idea of
keeping the price low. I personally wrote MINIX in my spare time, which is why
it doesn't have to follow the same rules as ACK.
Nevertheless, the source of the 8088 MINIX C compiler is available
as a separate package from UniPress. I suspect that the easiest way to get
a 68000 C compiler is for someone at a university to have their university buy
the ACK tape and use that to develop the 68000 compiler. When it is done, it
will be necessary to negotiate a deal with UniPress to allow it to be sold,
but I know Mark Krieger, the president of UniPress, and he is a reasonable guy,
so I am sure some deal can be worked out that won't raise the price too much.
He is on the net (msk@unipress.uucp) if you have questions about all this.
The reason that I think this route is the easiest, is that ACK already has a
backend for the 68000, so there isn't much work to be done, but you really
need a VAX or a SUN or something like that to bring up the full ACK development
system. The compilers that are produced aren't so big, but the compiler-
compilers, and backend generators and the other meta-software doesn't really
fit easily on a PC. In addition to the 6 megabytes of source code on the
tape, you have to count on at least 20 megabytes of object files and working
space to compile everything. The 68000 compiler has been running for years
and it is pretty good. We recently rewrote the backend table for the
68000, 68010, and 68020 and the code quality seems very good (about 15% better
than the C compiler Motorola sells). I haven't even thought about using the
Pascal, Modula 2, Basic etc. front ends because I wanted the system to fit on,
and be able to recompile itself on a system without, a hard disk. This
succeeded. Technically there shouldn't be any big problem with the other
front ends. Note that UniPress has TWO packages: 8088 MINIX C compiler, and
full ACK. The former is 4 diskettes; the latter is 6 megabytes on a mag tape.
Andy Tanenbaum (minix@cs.vu.nl, or in emergencies, minix@vu44.uucp)
Sizes of the MINIX commands
Program Text Data Bss Total (all sizes in decimal bytes)
sync: 424 20 26 470
clr: 714 28 156 898
update: 836 42 58 936
sleep: 848 58 58 964
ln: 1070 86 74 1230
chmod: 984 98 156 1238
basename: 1060 66 156 1282
tee: 1228 82 94 1404
kill: 1240 78 156 1474
umount: 782 758 26 1566
touch: 1348 76 156 1580
sum: 1438 84 156 1678
mknod: 930 738 26 1694
mount: 890 782 26 1698
pwd: 1546 84 172 1802
mkdir: 1656 158 58 1872
split: 1656 132 130 1918
rev: 886 42 1052 1980
rmdir: 1802 196 188 2186
cat: 1212 722 540 2474
mv: 2444 244 58 2746
echo: 648 24 2076 2748
stty: 2336 260 170 2766
rm: 2468 276 30 2774
df: 2030 948 156 3134
time: 2584 666 266 3516
lpr: 1314 126 2114 3554
comm: 1822 104 2400 4326
tr: 1470 82 2852 4404
login: 3376 1436 28 4840
chmem: 3178 278 2074 5530
size: 3102 232 2208 5542
tar: 4010 456 1774 6240
head: 2762 168 3484 6414
wc: 4460 208 2104 6772
su: 3548 1498 2076 7122
dd: 4966 532 2148 7646
chown: 3522 2148 2074 7744
date: 5338 412 2104 7854
od: 5388 288 3654 9330
passwd: 4976 1764 2620 9360
pr: 5776 514 3110 9400
sort: 6404 694 2490 9588
grep: 6740 694 2208 9642
uniq: 4956 850 5150 10956
cc: 4404 826 5986 11216
cc.at: 4404 834 5986 11224
gres: 8496 768 2076 11340
tail: 4550 184 7200 11934
ar: 4900 488 11350 16738
mkfs: 8708 906 7376 16990
roff: 12742 820 4710 18272
cp: 1914 876 16412 19202
make: 15216 1976 3614 20806
shar: 980 82 20506 21568
cmp: 3372 224 18468 22064
dosread: 7440 3688 11992 23120
mined: 15680 2198 5308 23186
sh: 21536 1668 1310 24514
ls: 7164 584 17994 25742
cpp: 16896 3764 8580 29240 (Pass 1 of the C compiler)
asld: 14048 7882 7412 29342 (Pass 5 of the C compiler)
opt: 16400 9368 9494 35262 (Pass 3 of the C compiler)
cg: 24816 22968 10520 58304 (Pass 4 of the C compiler)
cem: 59856 10656 3164 73676 (Pass 2 of the C compiler)
------------------------------
From: ast@botter.cs.vu.nl (Andy Tanenbaum)
Subject: MINIX
Date: 12 Jan 87 12:00:41 GMT
Organization: VU Informatica, Amsterdam
John Diamant has asked what the difference between the various MINIX packages
is. Here is a brief rundown. The binary of the operating system is identical
on the 256K and 640K PC version. The only difference is that the binary of
the C compiler has been deleted from the 256K version because some of the
passes are normally kept on the RAM disk, and with only 256K, the RAM disk is
too small to hold them. I just deleted the whole compiler, thus freeing up a
little extra space on the /usr diskette.
There are 3 differences between the 640K PC version and the 512K AT version:
1. The binary for the PC version has a hard disk driver for the XT type disk
embedded in it. The binary for the AT version has the AT type disk driver.
Both versions contain the source code for both the XT and AT drivers, so
if you upgrade your XT to an AT, you just have to recompile with the other
driver.
2. The AT version comes on five 1.2M diskettes instead of eight 360K diskettes.
The source programs present on both are identical.
3. The initial configuration of what is on the /usr diskette and what is on
the RAM disk is different. The compiler passes won't fit on the RAM disk
here either with only 512K, but there is plenty of room on the 1.2M
floppies.
If you have a 256K or 384K machine and a friend has a 640K machine, get the
640K system and make a new root file system (for the RAM disk) yourself using
mkfs. About 55K is the right size, and it should contain the same /etc and
/dev as the 640K system; /bin should have only: getlf, sh, and sync. If you
have 256K and two floppy disks or a hard disk, you can also copy the C compiler
to a second file system, but you have to fix and recompile the little driving
program cc.c because the paths of the compiler passes are built into it. If
you are going to put the compiler passes in /user/lib or somewhere else, you
have to change cc.c so it knows which files to EXEC. When moving the 640K PC
system to a 512K AT you have to make the same change. As distributed, cc.c
won't compile because I have intentionally included a line saying:
!!!!_SEE_BELOW_!!! on line 30 to attract your attention to the comment
explaining all this.
In summary, you can use the 640K system to reconstruct a RAM disk (root device)
for 256K or 384K or any other size using mkfs. You don't have to recompile
the operating system. The reason for two different sets is that the RAM disk
image (diskette #2) is different for 256K and 640K as described above. The
only kernel tuning utility is chmem, which changes the amount of stack space
allocated to a program.
The mag tape has all the sources but no binaries at all. It was intended for
university courses on operating systems that have to use a VAX for the student
projects. The tape contains a simulator for the IBM PC (8088 interpreter plus
some I/O device simulation) so students can modify MINIX on the VAX and run
it on the PC simulator. I would be less than honest to suggest that
interpreting a PC on a VAX is blindingly fast, but if you compile the C to
assembly code and then patch up the main decode loop by hand and hack away at
the condition code routine, you can help somewhat. The tape also contains
software to run the file-system-only via a pipe to a test program. This
runs at normal speed, but only allows the students to test the file system.
Neither of these directories are available on diskette. The complete PC
simulator is not a real small program :-) I have found the simulator very
useful for debugging however, as it has a wealth of options for tracing,
breakpoints, and other debugging.
I have had a lot of mail asking about uucp. I don't have one. If anyone has
a version that runs on V7 and isn't huge and works (a tall order), let me
know or post it.
There was also some discussion about whether or not B. Dalton deals in
textbooks. They certainly do. I have bought many textbooks at some of their
stores. The problem is this. Prentice-Hall, Addison-Wesley, and similar
publishers mostly sell to college book stores. The discount off list price is
based on the way college book stores work. B. Dalton simply says "We are big
and we want a bigger discount." This causes friction. Sometimes B. Dalton
gives in, sometimes the publisher gives in, and sometimes nobody gives in.
If your local B. Dalton refuses to order the book, try a college book store,
or Prentice-Hall's mail order dept.
Andy Tanenbaum
------------------------------
From: ast@botter.cs.vu.nl (Andy Tanenbaum)
Subject: MINIX
Date: 13 Jan 87 18:59:08 GMT
Organization: VU Informatica, Amsterdam
Bruce Martin writes:
> I suppose this should wait until I get the book, but I'm to interested and
> impatient.
>
> First, does MINIX run in the protected mode on an AT? If not, are there
> any plans to support it in the future?
>
> Secondly, has anyone given thought to adding swapping to MINIX. It
> would be very useful, and with hard drives becoming so common-place, not
> out of the question. It sounds like a lot of work (to me) but well worth
> the trouble.
>
MINIX does not use protected mode on the 286, but adding it wouldn't be that
hard, provided one didn't get overambitious and try to redesign the whole
memory management scheme to use all those segments. I don't have the time to
do it, but maybe someone else does.
Although hard disks are getting cheap, so is memory. I think a better
improvement would be to allow MINIX to use memory above 640K. On a system
with lots of memory and fairly small programs, swapping isn't so important.
Andy Tanenbaum (minix@cs.vu.nl)
------------------------------
From: ast@botter.cs.vu.nl (Andy Tanenbaum)
Subject: MINIX
Date: 15 Jan 87 12:01:29 GMT
While developing MINIX I was offered some software from people who shall here
remain nameless. This software consisted of utilities taken from AT&T UNIX
with the identifiers all changed, the layout modified, and a few changes here
and there. Needless to say I sent it all back, warning the authors that making
cosmetic changes to AT&T code does not suddenly void their copyright. If you
ever get taken to court for copyright violation the judge can easily find an
impartial expert witness and ask him if in his opinion the copy was based on
the original. If he says "yes" there will be trouble.
The MINIX utilities and libraries were all genuinely written from scratch,
without even peeking at the UNIX code. The only place you may find some
resemblance is in very small subroutines like strcmp. There are not really
a large number of fundamentally different algorithms for strcmp, so there
will be some similarity. For larger programs like ls or even cp, there
is no similarity at all.
The policy on posting MINIX source code is this. Although it is copyright,
if you have modified some file and think people might be interested in it,
it is ok to mail or post it. The only thing to keep in mind is that a
large amount of the network traffic goes over dial up phone lines, even if
your site happens to be on the ARPANET. When you post something, remember
that other people are paying the phone bills. If you want to post a large
file, it might be a good idea to first announce it and ask people to send
you mail if they are interested. If there isn't much response, mailing
it to a few people is much cheaper than posting it to the whole world.
On another subject, as you can imagine, I have gotten LOTS of mail, all
of it very encouraging. However, one person who works for a major defense
contractor said that his employer was planning to aquire MINIX to run on
some PCs. Perhaps a word of caution is in order. MINIX was designed with
the goal of being an educational tool, for teaching in university or
corporate classes, or studying yourself. It was also designed for hackers
to play with at home on their PCs, and things like that. I don't think I
would like to trust the defense of the entire Western World to it.
If you sort of have the vague notion that putting MINIX on your PC will
suddenly turn the PC into something like the VAX running 4.3 that you use at
work, you will be disappointed. What it does do, is turn the PC into something
roughly comparable to a low-end PDP-11 running V7.
Mark Harris posted a question concerning MINIX and the EGA board. I honestly
don't know if MINIX will work with the EGA board. I don't have access to
one. Since the terminal driver is very straightforward, if the EGA board
makes a reasonable attempt to emulate the 6845, patching the driver shouldn't
be too hard even if it doesn't work initially.
Andy Tanenbaum
------------------------------
From: tower@mit-eddie.MIT.EDU (Leonard H. Tower Jr.)
Date: 17 Jan 87 21:53:46 GMT
Subject: diffs between FSF/GNU, MINIX, AT&T Unix
In article <1026@botter.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
> ... The GNU people are
>upset because deep in their hearts they, too, know that people would rather
>pay a reasonable price for good stuff than get empty promises for free.
First, I would like to commend ast for doing MINIX, and going a large part of
the way towards giving MINIX its freedom.
Second, GNU isn't an empty promise. GNU Emacs is out there. GDB (GNU's
Debugger) is out there. Bison, a YACC compatible Parser Generator, is out
there. The GNU C compiler (highly optimizing with VAX, 68000, and 68020 code
generators) will be released soon. Etc.
The remaining large undone piece is the kernel. Work has started on that,
and its being leveraged off of existing code for a Unix style kernel, Trix,
written at MIT a while back.
GNU is a more ambitious project than MINIX, and rms hasn't had much more help
than ast. Most of rms' help has been volunteer. rms has also been working on
it for a shorter period of time.
Third, none of the GNU people I know of are upset. We are just sad that yet
more software has been chained up.
>Does anyone know how much GNU charges for its "free" software for the tape,
>postage, handling etc? Berkeley generally charges something like $125
>for its tapes, as I recall. If GNU also charges $125 for its "free" software
>it seems to me that their moral indignation at Prentice-Hall's outrageous
>$79.95 price is somewhat weakened.
First, "free" doesn't refer to cost, but to the freedom of the software.
Second, I would like to present some comparisons between GNU, MINIX, and
Unix. I know the facts are straight for GNU, correct me on the others.
GNU MINIX Unix
--- ----- ----
Is source code distributed? Yes Yes For many more $$
How many copies of the source can
you give away, legally? Unlimited 3-4 None
Can one legally restrict use by others? No YES YES
Can one legally post it on USENET? Yes NO NO
Can one legally ARPA ftp it, freely? Yes NO NO
Cost of non-ARPA distribution from
home organization: $ 150. $ 80. Many times more.
People are referred to:
- the GNU Public License
- the GNU Manifesto
- Minix's Licensing arrangements (I have yet to see these)
- AT&T and susbsidiary vendor Unix Licenses
for further details.
happy hacking, len tower
Len Tower, Project GNU of the Free Software Foundation
1000 Mass. Ave., Cambridge, MA 02138, USA +1 (617) 876-3296
HOME: 36 Porter Street, Somerville, MA 02143, USA +1 (617) 623-7739
UUCP: {}!mit-eddie!mit-prep!tower INTERNET: tower@prep.ai.mit.edu
------------------------------
From: ast@botter.cs.vu.nl (Andy Tanenbaum)
Subject: MINIX - A Technical Description
Date: 15 Jan 87 22:54:20 GMT
Below is an extract of the paper I will be presenting at UNIFORUM on Jan 22.
I may try to set up a BOF session on MINIX at USENIX for the benefit of
people not going to UNIFORUM (I originally submitted my paper to USENIX
but it was rejected because it didn't fit in anywhere). Check the listings.
I am going to Palo Alto after the meetings, and won't be back reading my mail
until early February.
Well over 100 people have written me expressing interest in comp.os.minix.
I have communicated this to the net adminstrators.
Andy Tanenbaum
MINIX: A CHEAP UNIX CLONE WITH SOURCE CODE
Andrew S. Tanenbaum
Dept. of Mathematics and Computer Science
Vrije Universiteit
Amsterdam, The Netherlands
1. OVERVIEW OF THE MINIX SYSTEM ARCHITECTURE
UNIX is organized as a single executable program that
is loaded into memory at system boot time and then run.
MINIX is structured in a much more modular way, as a collec-
tion of processes that communicate with each other and with
user processes by sending and receiving messages. There are
separate processes for the memory manager, the file system,
for each device driver, and for certain other system func-
tions. This structure enforces a better interface between
the pieces. The file system cannot, for example, acciden-
tally change the memory manager's tables because the file
system and memory manager each have their own private
address spaces.
These system processes are each full-fledged processes,
with their own memory allocation, process table entry and
state. They can be run, blocked, and send messages, just as
the user processes. In fact, the memory manager and file
system each run in user space as ordinary processes. The
device drivers are all linked together with the kernel into
the same binary program, but they communicate with each
other and with the other processes by message passing.
When the system is compiled, four binary programs are
independently created: the kernel (including the driver
processes), the memory manager, the file system, and init
(which reads /etc/ttys and forks off the login processes).
In other words, compiling the system results in four dis-
tinct a.out files. When the system is booted, all four of
these are read into memory from the boot diskette.
It is possible, and in fact, normal, to modify, recom-
pile, and relink, say, the file system, without having to
relink the other three pieces. This design provides a high
degree of modularity by dividing the system up into indepen-
dent pieces, each with a well-defined function and interface
to the other pieces. The pieces communicate by sending and
receiving messages.
The various processes are structured in four layers:
4. The user processes (top layer).
3. The server processes (memory manager and file system).
2. The device drivers, one process per device.
1. Process and message handling (bottom layer).
Let us now briefly summarize the function of each layer:
Layer 1 is concerned with doing process management
including CPU scheduling and interprocess communication.
When a process does a SEND or RECEIVE, it traps to the ker-
nel, which then tries to execute the command. If the com-
mand cannot be executed (e.g., a process does a RECEIVE and
there are no messages waiting for it), the caller is blocked
until the command can be executed, at which time the process
is reactivated. When an interrupt occurs, layer 1 converts
it into a message to the appropriate device driver, which
will normally be blocked waiting for it. The decision about
which process to run when is also made in layer 1. A prior-
ity algorithm is used, giving device drivers higher priority
over ordinary user processes, for example.
Layer 2 contains the device drivers, one process per
major device. These processes are part of the kernel's
address space because they must run in kernel mode to access
I/O device registers and execute I/O instructions. Although
the IBM PC does not have user mode/kernel mode, most other
machines do, so this decision has been made with an eye
toward the future. To distinguish the processes within the
kernel from those in user space, the kernel processes are
called tasks.
Layer 3 contains only two processes, the memory manager
and the file system. They are both structured as servers,
with the user processes as clients. When a user process
(i.e., a client) wants to execute a system call, it calls,
for example, the library procedure read with the file
descriptor, buffer, and count. The library procedure builds
a message containing the system call number and the parame-
ters and sends it to the file system. The client then
blocks waiting for a reply. When the file system receives
the message, it carries it out and sends back a reply con-
taining the number of bytes read or the error code. The
library procedure gets the reply and returns the result to
the caller in the usual way. The user is completely unaware
of what is going on here, making it easy to replace the
local file system with a remote one.
Layer 4 contains the user programs. When the system
comes up, init forks off login processes, which then wait
for input. On a successful login, the shell is executed.
Processes can fork, resulting in a tree of processes, with
init at the root. When CTRL-D is typed to a shell, it
exits, and init replaces the shell with another login pro-
cess.
2. LAYER 1 - PROCESSES AND MESSAGES
The two basic concepts on which MINIX is built are
processes and messages. A process is an independently
schedulable entity with its own process table entry. A mes-
sage is a structure containing the sender's process number,
a message type field, and a variable part (a union) contain-
ing the parameters or reply codes of the message. Message
size is fixed, depending on how big the union happens to be
on the machine in question. On the IBM PC it is 24 bytes.
Three kernel calls are provided:
- RECEIVE(source, &message)
- SEND(destination, &message)
- SENDREC(process, &message)
These are the only true system calls (i.e., traps to the
kernel). RECEIVE announces the willingness of the caller to
accept a message from a specified process, or ANY, if the
RECEIVER will accept any message. (From here on, ``pro-
cess'' also includes the tasks.) If no message is available,
the receiving process is blocked. SEND attempts to transmit
a message to the destination process. If the destination
process is currently blocked trying to receive from the
sender, the kernel copies the message from the sender's
buffer to the receiver's buffer, and then marks them both as
runnable. If the receiver is not waiting for a message from
the sender, the sender is blocked.
The SENDREC primitive combines the functions of the
other two. It sends a message to the indicated process, and
then blocks until a reply has been received. The reply
overwrites the original message. User processes use SENDREC
to execute system calls by sending messages to the servers
and then blocking until the reply arrives.
There are two ways to enter the kernel. One way is by
the trap resulting from a process' attempt to send or
receive a message. The other way is by an interrupt. When
an interrupt occurs, the registers and machine state of the
currently running process are saved in its process table
entry. Then a general interrupt handler is called with the
interrupt number as parameter. This procedure builds a mes-
sage of type INTERRUPT, copies it to the buffer of the wait-
ing task, marks that task as runnable (unblocked), and then
calls the scheduler to see who to run next.
The scheduler maintains three queues, corresponding to
layers 2, 3, and 4, respectively. The driver queue has the
highest priority, the server queue has middle priority, and
the user queue has lowest priority. The scheduling algo-
rithm is simple: find the highest priority queue that has at
least one process on it, and run the first process on that
queue. In this way, a clock interrupt will cause a process
switch if the file system was running, but not if the disk
driver was running. If the disk driver was running, the
clock task will be put at the end of the highest priority
queue, and run when its turn comes.
In addition to this rule, once every 100 msec, the
clock task checks to see if the current process is a user
process that has been running for at least 100 msec. If so,
that user is removed from the front of the user queue and
put on the back. In effect, compute bound user processes
are run using a round robin scheduler. Once started, a user
process runs until either it blocks trying to send or
receive a message, or it has had 100 msec of CPU time. This
algorithm is simple, fair, and easy to implement.
3. LAYER 2 - DEVICE DRIVERS
Like all versions of UNIX for the IBM PC, MINIX does
not use the ROM BIOS for input or output because the BIOS
does not support interrupts. Suppose a user forks off a
compilation in the background and then calls the editor. If
the editor tried to read from the terminal using the BIOS,
the compilation (and any other background jobs such as
printing) would be stopped dead in their tracks waiting for
the the next character to be typed. Such behavior may be
acceptable in the MS-DOS world, but it certainly is not in
the UNIX world. As a result, MINIX contains a complete set
of drivers that duplicate the functions of the BIOS. Like
the rest of MINIX, these drivers are written in C, not
assembly language.
This design has important implications for running
MINIX on PC clones. A clone whose hardware is not compati-
ble with the PC down to the chip level, but which tries to
hide the differences by making the BIOS calls functionally
identical to IBM's will not run an unmodified MINIX because
MINIX does not use the BIOS.
Each device driver is a separate process in MINIX. At
present, the drivers include the clock driver, terminal
driver, various disk drivers (e.g., RAM disk, floppy disk),
and printer driver. Each driver has a main loop consisting
of three actions:
1. Wait for an incoming message.
2. Perform the request contained in the message.
3. Send a reply message.
Request messages have a standard format, containing the
opcode (e.g., READ, WRITE, or IOCTL), the minor device
number, the position (e.g., disk block number), the buffer
address, the byte count, and the number of the process on
whose behalf the work is being done.
As an example of where device drivers fit in, consider
what happens when a user wants to read from a file. The
user sends a message to the file system. If the file system
has the needed data in its buffer cache, they are copied
back to the user. Otherwise, the file system sends a mes-
sage to the disk task requesting that the block be read into
a buffer within the file system's address space (in its
cache). Users may not send messages to the tasks directly.
Only the servers may do this.
MINIX supports a RAM disk. In fact, the RAM disk is
always used to hold the root device. When the system is
booted, after the operating system has been loaded, the user
is instructed to insert the root file system diskette. The
file system then sees how big it is, allocates the necessary
memory, and copies the diskette to the RAM disk. Other file
systems can then be mounted on the root device.
This organization puts important directories such as
/bin and /tmp on the fastest device, and also makes it easy
to work with either floppy disks or hard disks or a mixture
of the two by mounting them on /usr or /user or elsewhere.
In any event, the root device is always in the same place.
In the standard distribution, the RAM disk is about
240K, most of which is full of parts of the C compiler. In
the 256K system, a much smaller RAM disk has to be used,
which explains why this version has no C compiler: there is
no place to put it. (The /usr diskette is completely full
with the other utility programs and one of the design goals
was to make the system run on a 256K PC with 1 floppy disk.)
Users with an unusual configuration such as 256K and three
hard disks are free to juggle things around as they see fit.
The terminal driver is compatible with the standard V7
terminal driver. It supports cooked mode, raw mode, and
cbreak mode. It also supports several escape sequences,
such as cursor positioning and reverse scrolling because the
screen editor needs them.
The printer driver copies its input to the printer
character for character without modification. It does not
even convert line feed to carriage return + line feed. This
makes it possible to send escape sequences to graphics
printers without the driver messing things up. MINIX does
not spool output because floppy disk systems rarely have
enough spare disk space for the spooling directory. Instead
one normally would print a file f by saying
lpr <f &
to do the printing in the background. The lpr program
insert carriage returns, expands tabs, and so on, so it
should only be used for straight ASCII files. On hard disk
systems, a spooler would not be difficult to write.
4. LAYER 3 - SERVERS
Layer 3 contains two server processes: the memory
manager and the file system. They are both structured in
the same way as the device drivers, that is a main loop that
accepts requests, performs them, and then replies. We will
now look at each of these in turn.
The memory manager's job is to handle those system
calls that affect memory allocation, as well as a few oth-
ers. These include FORK, EXEC, WAIT, KILL, and BRK. The
memory model used by MINIX is exceptionally simple in order
to accommodate computers without any memory management
hardware. When the shell forks off a process, a copy of the
shell is made in memory. When the child does an EXEC, the
new core image is placed in memory. Thereafter it is never
moved. MINIX does not swap or page.
The amount of memory allocated to the process is deter-
mined by a field in the header of the executable file. A
program, chmem, has been provided to manipulate this field.
When a process is started, the text segment is set at the
very bottom of the allocated memory area, followed by the
data and bss. The stack starts at the top of the allocated
memory and grows downward. The space between the bottom of
the stack and the top of the data segment is available for
both segments to grow into as needed. If the two segments
meet, the process is killed.
In the past, before paging was invented, all memory
allocation schemes worked like this. In the future, when
even small microcomputers will use 32-bit CPUs and 1M x 1
bit memory chips, the minimum feasible memory will be 4
megabytes and this allocation scheme will probably become
popular again due to its inherent simplicity. Thus the
MINIX scheme can be regarded as either hopelessly outdated
or amazingly futuristic, as you prefer.
The memory manager keeps track of memory using a list
of holes. When new memory is needed, either for FORK or for
EXEC, it searches the hole list and takes the first hole
that is big enough (first fit). When a process terminates,
if it is adjacent to a hole on either side, the process'
memory and the hole are merged into a bigger hole.
The file system is really a remote file server that
happens to be running on the user's machine. However it is
straightforward to convert it into a true network file
server. All that needs to be done is change the message
interface and provide some way of authenticating requests.
(In MINIX, the source field in the incoming message is
trustworthy because it is filled in by the kernel.) When
running remote, the MINIX file server maintains state infor-
mation, like RFS and unlike NFS.
The MINIX file system is similar to that of V7 UNIX.
The i-node is slightly different, containing only 9 disk
addresses instead of 13, and only 1 time instead of 3.
These changes reduce the i-node from 64 bytes to 32 bytes,
to store more i-nodes per disk block and reduce the size of
the in-core i-node table.
Free disk blocks and free inodes are kept track of
using bit maps rather than free lists. The bit maps for the
root device and all mounted file systems are kept in memory.
When a file grows, the system makes a definite effort to
allocate the new block as close as possible to the old ones,
to minimize arm motion. Disk storage is not necessarily
allocated one block at a time. A minor device can be con-
figured to allocate 2, 4 (or more) contiguous blocks when-
ever a block is allocated. Although this wastes disk space,
these multiblock zones improve disk performance by keeping
file blocks close together. The standard parameters for
MINIX as distributed are 1K blocks and 1K zones (i.e., just
1 block per zone).
MINIX maintains a buffer cache of recently used blocks.
A hashing algorithm is used to look up blocks in the cache.
When an i-node block, directory block, or other critical
block is modified, it is written back to disk immediately.
Data blocks are only written back at the next SYNC or when
the buffer is needed for something else.
The MINIX directory system and format is identical to
that of V7 UNIX. File names are strings of up to 14 charac-
ters, and directories can be arbitrarily long.
5. LAYER 4 - USER PROCESSES
This layer contains init, the shell, the editor, the
compiler, the utilities, and all the user processes. These
processes may only send messages to the memory manager and
the file system, and these servers only accept valid system
call requests. Thus the user processes do not perceive
MINIX to be a general-purpose message passing system. How-
ever, removing the one line of code that checks if the mes-
sage destination is valid would convert it into a much more
general system (but less UNIX-like).
------------------------------
From: henry@utzoo.UUCP (Henry Spencer)
Subject: V7 Syscalls List?
Date: 16 Jan 87 19:38:05 GMT
Organization: U of Toronto Zoology
> Can anyone provide a list of the version 7 system calls? ...
Here is the full list, from sysent.c of a functioning V7 (utzoo
is an 11/44 running V7, although not for much longer).
access
acct
alarm
brk (also does sbrk)
chdir
chmod
chown
chroot
close
creat
dup (also does dup2)
exec (obsolete, see exece)
exece (generic, includes execl, execv, execle, execve)
exit
fork
fstat
ftime
getgid (also does getegid)
getpid
getuid (also does geteuid)
gtty (obsolete; invokes ioctl internally)
indir (silly kludge probably unnecessary on non-11 systems)
ioctl
kill
link
lock (lock process into memory)
lseek
mknod (makes directories and devices)
mount
mpxchan (you don't want to know... not in all V7s)
nice
open
pause
phys (map memory into user space)
pipe
profil
ptrace
read
setgid
setuid
signal
stat
stime
stty (obsolete; invokes ioctl internally)
sync
time
times
umask
umount
unlink
utime
wait
write
--
Legalize Henry Spencer @ U of Toronto Zoology
freedom! {allegra,ihnp4,decvax,pyramid}!utzoo!henry
------------------------------
From: ast@botter.cs.vu.nl (Andy Tanenbaum)
Subject: MINIX Newsgroup Exists
Date: 18 Jan 87 14:21:08 GMT
The comp.os.minix newsgroup has been set up. Discussion about MINIX can
now move there, leaving the comp.sys.ibm.pc people to wallow in MS-DOS.
Thanks to all the people who wrote to me and posted notes in support of it.
Some of the topics that might be worth discussing in comp.os.minix are:
1. Questions of general interest (for other questions, send me mail)
2. Bug reports
3. Bug fixes (it is ok to post individual files)
4. Experience with MINIX on various machines
5. Discussions about ports to different CPUs, etc.
6. Discussions about networking, news, uucp, etc., none of which exist now
7. New drivers
8. New utilities
9. Experience with MINIX for use in courses (e.g., sample student projects)
The port of MINIX to the Atari ST is now fully underway. Please don't ask
me when it will be done, since neither I nor the people doing it know.
As with any software project, the first 99% is the easy part. I will post
status reports when there is status to report.
Several people have asked me whether MINIX runs on the brand XYZ clone.
It has been briefly tried on a few clones, but not really thoroughly, and I
wouldn't want to promise that it worked on some machine if I wasn't absolutely
sure. As people get the code and try it out on various machines and with
various nonstandard boards, please post your findings to comp.os.minix.
The same is true of hard disks. Since MINIX directly addresses the disk
controller, it will only work with controllers that are identical to the
IBM XT or AT. In fact, it has only been tried on the standard XT and the
(old) 6 MHz AT. I assume (hope ?) that the (new) 8 Mhz AT uses the same
controller as the old one, even though the drive is larger. Similarly, I
haven't tried it on the XT-286. I don't have access to these machines.
Len Tower posted a message comparing GNU, MINIX, and UNIX. It may be true
that even at $150, GNU is more "free" in some sense than MINIX at $80.
If and when the GNU kernel, device drivers, utilities, and documentation
have been written, debugged, integrated, ported to some common machine, and
distributed, we can better evaluate it in other ways.
Some people have been having trouble getting through to me. One person even
posted a note to the world-wide net in desperation. The address to use for
mail to me about MINIX is minix@cs.vu.nl. For those people whose mailer
is not yet converted to domain notation, use minix@vu44.uucp, but this will
vanish eventually.
Andy Tanenbaum
------------------------------
From: ganesh@utah-cs.UUCP (Ganesh C Gopalakrishnan)
Subject: 1. MINIX can run on.. 2. Disk part. 3. Caveats 4. 512K 5. Kudos
Date: 22 Jan 87 16:43:37 GMT
Organization: University of Utah CS Dept
(1) I've succesfully run MINIX on the Leading Edge clone of
an ordinary IBM-PC (forget the model number),
an ordinary PC, and a Samsung Clone. My friends have
run it on a PC-XT and a PC-AT. If you are interested, mail me a note
and I'll get the exact model numbers.
CAVEAT : I haven't tested and confirmed that all the device
drivers would operate correctly on the clones. My OS class (45 students)
is using Minix on the Leading Edges, and I will find this out
soon.
(2) The book (yes, I got one courtesy of PH)
gives instructions on how to fool the DOS program
FDISK into making multiple partitions, one for DOS, one for
MINIX, etc. However, read (3).
(3) THE HARD-CARD 20 SOLD BY MAYNARD COPR. isn't compatible with
the driver provided for Minix. I learned this the painful way, but
could return my HARD-CARD anyway (because it was also hogging too much power
and causing floppy errors after long hours of use!).
(4) 512 K : I've compiled some small C programs on a 512K machine.
The number of processes that you can run are severely limited.
You can't stop the full screen editor "Mined" because it runs out
of room in an attempt to fork.
There are ways of circumventing the lack of a full 640 K (by moving
programs around to leave enough space on the RAM disk, etc.). I'd
rather spend the extra $20 that it costs these days to get a system
upgraded to 640 K, if you have the space on the memory board.
(5) Finally, Kudos to Andy Tanenbaum and students for their
mammoth effort. The system is really rugged and well documented.
I could recompile and re-build the system with ease.
The book is packed with information.
I think I've run into one minor bug so far, and I will post more details
after I study it closely myself.
Ganesh
------------------------------
Date: 21 Jan 87 22:37 PST
From: BSF.COR@OFFICE-1.ARPA
Subject: MINIX Talk
Computer Literacy Bookstore has asked me to pass the word that Dr. Andrew
Tanenbaum will be at their new store on Wed, Jan 28, 1987 at 7:00 pm to discuss
MINIX.
Computer Literacy Bookstore
Techmart
5201 Great America Parkway (at Tasman)
Santa Clara, Ca
(408) 562-5799
Bill Frantz - Key Logic
------------------------------
End of Info-IBMPC Digest
************************
-------