ast@botter.UUCP (02/10/87)
Here are some questions and answers from recent news and mail.
Q1: Does the PC simulator on the tape have parts in assembler?
A1: No. It is 100% C. It should be easy to port anywhere with a C compiler
and enough memory (about 1.5M). Only caution is big vs. little endian.
Q2: Why did you have the C compiler produce packed assembly code?
A2: I didn't have a separate assembler and loader. All I had was a single
program, asld, that assembled and loaded all at once. Given this program,
packed assembly code was better than ASCII assembly code. MINIX has
programs libupack and libpack to go both ways. I admit it is a kludge,
but time constraints prohibited me from writing an assembler and a loader,
and asld was available and well-debugged.
Q3: Why wasn't the code produced as a separate volume, like John Lions' book?
A3: I discussed this with P-H at great length. Given the way book publishing
works, a two volume set would have greatly increased the price of the
book, and neither P-H nor I wanted that.
Q4: Any news on new clones that MINIX works on or doesn't work on?
A4: Our dept. has just gotten a large shipment of Zenith Z-248 AT clones for
student use. It works fine, provided the machine has a standard graphics
board that works the way the IBM mono or color board works. It doesn't
work quite right with the EGA board. I don't know why EGA board manuals
are scarcer than hen's teeth around here. Even Zenith doesn't have the
manual for their own board. I also discovered a class of hard disks that
the MINIX disk driver can't handle. The default block size is 1K, which
means two sectors on most drives. On a drive with an odd number of 512-
byte sectors per cylinder, the last logical block will be split over two
cylinders. On drives that can't handle the implied seek, the driver gives
up and reports an unrecoverable error. The driver is being modified to
handle this situation by simple reading each sector one at a time. The
AT driver on the MINIX distribution worked fine with the Zenith 20 MB hard
disk, but not with the 30 MB disk, which has 85 sectors per cylinder.
Q5: Why didn't you use the BIOS?
A5: Because it doesn't support interrupts. If a foreground job, like a
shell or editor read from the terminal by calling the BIOS, all the
background jobs would be stopped instantly. The BIOS simply does not
support multiprogramming at all. On the AT it has some crude hooks,
but I wanted the PC and AT versions to be the same. I don't think that
will last long, but at least no one can blame me for the divergence.
Q6: Where is get_tot_mem? I can't find it in the cross reference map.
A6: It is in lib/getutil.s, which is on the disks but not in the book.
All the kernel library routines are in kernel/klib88.s and are in the
book. There are a couple of very short assembler routines that were
needed in MM and/or FS, and they got put in the lib directory with
the other library routines. Note that the library source routines
are in a MINIX archive lib lib/libsrc.a (to save disk space) so you
have to unpack the archive to get them.
There has been a lot of discussion about how to post source code. It seems
to me that the advantage of readable archives (i.e. shar) is so great that
tar just can't compare at all. Since MINIX includes a shar, it would seem
that the format produced by this shar should be the standard, since everyone
will have it. Of course one can create a "guest" uid and log in as guest
to limit the damage when unsharing. Someone made a comment about gres.
The MINIX shar format expects a gres, but thanks to Martin Atkins of York
MINIX has a gres, so there is no problem.
There was a program uuslave.c posted to comp.sources.unix a couple of days
ago. Does anyone know anything about this program? Might it be useful as
a first step toward uucp? If anyone has the time and knowledge, please take
a look at it and post your findings.
Andy Tanenbaum