[comp.os.minix] Progress report on MINIX 1.5.0

ast@cs.vu.nl (Andy Tanenbaum) (11/20/89)

I am actually making progress.  For simplicity, I have gone over to a three
part numbering scheme, so the next posting will be called 1.5.0.  I regard
Bruce Evans' PM posting as 1.4.1, and my current internal version as 1.4.2.
I will no doubt have vast numbers of versions differing in the third digit,
but only a few will go public.

I am going away for two weeks on Dec. 1, and I expect that I will have posted
a large chunk of 1.5.0 before I go.  Probably include, lib, commands, and doc
but not kernel, fs, mm, h.  That will have to wait until I get back.  If
there are a few experienced MINIX users who want to serve as beta sites for
the 1.5.0 kernel and have plenty of time from 1 Dec to 14 Dec, let me know.

I am grappling with configuration issues now.  There is a new file, h/config.h
that contains a lot of the configuration stuff.  In addition, there is
the issue of how to handle Bruce's 32-bit stuff.  The solution
will probably be a shell script called "config".  The idea is that before
making MINIX, you type "config" and it asks you questions.  Based on the
answers, it copies various files around.  For example, if you have an MFM type
disk, it will copy at_wini.c to win.c, but if you have a PS/2 model 30,
it will copy ps_wini.c to wini.c.

While I am at it, I think I can handle mice, graphics, etc. in the same way.
My idea is to always include mouse.c, graphics.c, etc.  These are
simply included in the makefile, not ifdef'ed or anything like that.
The kernel directory would then come with Mouse.c, Graphics.c, etc. as well
as a null driver, nodriver.c.  Depending on the answer to the question:
 Do you want to include the mouse driver (y/n)?
either Mouse.c or nodriver.c is copied to mouse.c.  This scheme has the
advantage of being simple, but the disadvantage of adding 88 bytes to the
kernel for each nodriver selected (I measured it).    If we eventually
have, say, 5 optional drivers, then there are 32 combinations and having a
makefile entry for each is horrid.  So if generating makefiles on the fly, etc.
If somebody has a simpler scheme, please post it.  I don't have a mouse
driver at present, but looking at the news, there will probably be one soon.

Andy Tanenbaum (ast@cs.vu.nl)

bediako@marvin.cs.Buffalo.EDU (Bernard Bediako) (11/21/89)

Is the 1.5.0 version going to contain #ifdef 's for all the different 
architectures (IBM,ST, MAC, etc) or is it only going to be for the PC?
What's the policy on getting MINIX for one computer, when you already
have for another?

bernie
bediako@cs,buffalo.edu
Bernard Bediako  --------=-=-=-=-=->	DOMAIN:	bediako@cs.buffalo.edu

jonah@db.toronto.edu (Jeffrey Lee) (11/21/89)

bediako@marvin.cs.Buffalo.EDU (Bernard Bediako) writes:
>Is the 1.5.0 version going to contain #ifdef 's for all the different 
>architectures (IBM,ST, MAC, etc) or is it only going to be for the PC?

Past experience with "portable" editors suggests that it is much better
to isolate system dependencies in separate files rather than use ifdefs
if at all possible.  This requires a considerable amount of foresight
and well defined module interfaces with information hiding.  I don't
know how easily this practice could be applied to the existing versions
of Minix.

j.