Path: utzoo!attcan!uunet!husc6!bloom-beacon!gatech!purdue!decwrl!hplabs!hpda!hpcupt1!hpcuhb!hpindda!vandys
From: vandys@hpindda.HP.COM (Andy Valencia)
Newsgroups: comp.os.minix
Subject: Re: MINIX in an OS class (very long)
Message-ID: <3580012@hpindda.HP.COM>
Date: 17 May 88 15:59:48 GMT
References: <11735@duke.cs.duke.edu>
Organization: HP Technical Networks, Cupertino, Calif.
Lines: 32


	Thank you for the excellent review of the MINIX book's material!
I'm going to file these comments away with the book itself (in case I
ever have to teach a course).  Let me add a couple of points which came to
mind while reading your comments.

1. Development cycle speed
	I started out doing my RS-232 driver for MINIX on an XT (4.77 Mhz)
with dual floppies.  Very quickly I got a hard drive partition working,
and then got an Orchid accelerator.  This made it just barely tolerable.
Since I was changing tty.c, and since that's where the kernel printf()s
go, I perhaps had a worse time than others might.  By the time you're running
a turbo AT (mine is 10Mhz, no wait states), the whole picture has changed--
compiles zip by at a reasonable rate.  I bet a '386 would be something
to see!

2. The simulator
	Don't count on it for an increase in performance--after all,
it's trying to emulate one machine on another.  I'd say your $$$ would
be better spent upgrading those XTs to clone turbo ATs, rather than
trying to make your campus minis run fast enough to support a class full
of students running the simulator.

3. Driver writing
	As it turns out, it is much easier to write drivers for UNIX
than MINIX.  UNIX has a fairly stable and well-designed set of routines
to use--very much refined over time.  This may be little comfort to the
student taking your class, but it might ease their minds about getting
a job doing UNIX kernel maintenance!

					Andy Valencia
					vandys%hpindda.UUCP@hplabs.hp.com