Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!cs.utexas.edu!uunet!mcvax!hp4nl!phigate!prle!prles2!cstw01!meulenbr
From: meulenbr@cstw01.prl.philips.nl (Frans Meulenbroeks)
Newsgroups: comp.os.minix
Subject: Re: The future of MINIX
Message-ID: <563@prles2.UUCP>
Date: 10 Jul 89 15:07:52 GMT
References: <2835@ast.cs.vu.nl>
Sender: nobody@prles2.UUCP
Reply-To: meulenbr@cstw01.prl.philips.nl (Frans Meulenbroeks)
Organization: Centre for Software Technology, Philips Eindhoven
Lines: 85

[lots of text discarded]
In article <2835@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
[...]
>Anyway, I have decided to use Bruce's code as the basis for V2.0 (subject to
>Prentice-Hall not vetoing a 900 page book).
[...]
>starting to work on POSIX.  I'll do the kernel/FS/MM myself (looking at
>what Simon Poole has already done), but help writing/converting libraries,
>utilities etc is very welcome.
>
>When all that is done, we will have a protected mode system that is based
>on POSIX and reasonably fast for small machines.  MINIX seems to be
>evolving in the direction of something more than an academic toy and towards
>a more serious system.  If I run into Niklaus Wirth at a conference 
>sometime, I'll have to ask him about that :-).
>
>An additional note.  Amiga MINIX is actually up and running.  It is now
>being tested.
>
>Furthermore, MINIX 1.3 is being ported to the SPARC.
>
>Getting all these versions back together, and then POSIX-based is going to be
>a job on the order of cleaning out the Augean Stables, and I don't have a
>Hercules card.
>
>Andy Tanenbaum (ast@cs.vu.nl)

Ok. That amounts to 5 different versions:
for 8088, 286/protected, ST, Amiga, SPARC. 

As far as getting these together: 
This can really become a pain. 
However, I would support such an integration very much.

As far as I can see it there are two different problem areas:
- assembly code 
  Since these must be rewritten completely, IMHO they should be avoided
  as much as possible. I know that it is tempting to do a lot of rs232
  stuff in assembly for performance purposes. However I would like to
  ask to limit this to the bare minimum.
- hardware dependencies
  This is another problem, which mainly arises in the tty/rs232/console
  area. Please do not rely on the fact that every system has a 8250
  chip. In the current tty.c there are a lot of places where the 8250 is
  enabled. I would suggest to keep all hardware independent stuff in
  tty.c, and either put all hardware stuff in say console.c and rs232.c
  or put it in dedicated files like i8250.c and so on, dealing with the
  various hardware components.
  Doing things this way yields a clear separation of the common part
  and the hardware specific part.
  If ast decides to isolate the hardware depencies in one way or
  another, I could be persuaded to look at the ST part of it.
  (By the way, the above does mainly apply to rs232, keyboard and
  monitor. I don't know if such an approach is feasible for floppy and
  hard disk).

On a related but different topic:
will something be done to get the compiler more ansi conformant?
I'm mainly thinking about function prototypes and floating point
support. 

As an aside:
I have a version of 1.4a for the ST, but I really don't know what to do
with it. Since I prefer very much to have an official upgrade
I'm very reluctant to post this.
On the other hand: I've shipped this to Johan Stevenson for
authorisation and posting somewhere in April, but it seems that he does
not have the time to look into it, and approve it.

I'm sitting on this stuff for more than two months now, and I feel in
some kind of catch-22 situation. What is the opinion of the net in
general and ast specifically that I should do with this stuff??

Note: please don't send mail requesting me to mail you a copy.
I want to get the minix community in sync, and I definitely don't want
a lot of different version floating around.

(by the way: this ST version is compatible with 1.4a, except for the
amoeba stuff. It does support rs232 (at least at 1200 baud))

regards,

Frans Meulenbroeks        (meulenbr@cst.prl.philips.nl)
	Centre for Software Technology
	( or try: ...!mcvax!phigate!prle!cst!meulenbr)