Path: utzoo!utgpu!attcan!uunet!husc6!purdue!haven!mimsy!jds
From: jds@mimsy.UUCP (James da Silva)
Newsgroups: comp.os.minix
Subject: Re: Minix on 386 machines
Message-ID: <15061@mimsy.UUCP>
Date: 19 Dec 88 02:35:51 GMT
References: <5998@louie.udel.EDU>
Reply-To: jds@mimsy.umd.edu (James da Silva)
Organization: University of Maryland, Department of Computer Science
Lines: 62

In article <5998@louie.udel.EDU> HELMER%SDNET.BITNET@vm1.nodak.edu (Guy Helmer)
writes:
>Update regarding a 386 Minix:
>I posted a message about a week ago asking for information regarding
>Minix on 386 machines.  Apparently, no special 386 Minix exists.

In October Bruce Evans mentioned (in <1776@runx.ips.oz>) progress he had
made to get Minix running in protected mode on the 386.  How's it going,
Bruce?

Marty Leisner has had Minix running in protected mode on his 286 for over a
year and a half, but hasn't made his changes public (that I know of).

Others have posted their intent to do the port to 386 PM, but without
substantial results to date (that I know of).  So the area has been
explored, and is overripe for the picking.

>What a few of us intend to do is create a 386 version of Minix that
>will definitely:
>   - Use demand-paged virtual memory (giving access to 4Gb address space)
>   - Use hardware task management (for super-fast task switching)
>   - Implement message queueing (to eliminate lots of problems)
>It has been suggested that making the file system map files into
>virtual memory would be good (apparently like SUN/OS 4.0), which
>sounds like a good idea.

Very Ambitious.  If you're planning on finishing anytime soon you will have
to cut the job up into little pieces.  I've thought about this in some
detail, and I really beleive that if we stick to the KISS principle we can
have a 386 (and a 286) Minix that makes good use of the hardware, but stays
close to the MINix philosophy.

Note that without paging activated, the 386 protected mode looks just like
the 286 protected mode, except that addresses, data and registers are 32
bits, and there's the I/O Permission Bit Map tacked at the end of the TSS
(yes, I'm simplifying).

Because of the strong family resemblance, I think the first thing to do is
get a 286 PM version going.  This should be straightforward, and doesn't
require 32 bit development tools.

The second phase would be to find a 32 bit development environment (GNU!)
and compile the kernel with it.  Only small changes should be necessary to
go from 286 descriptors and task state segments to the 386 variety, and to
clean up whatever 16-bit dependencies there are (like most of the asm code,
probably).  Some extra work will be necessary to support 16-bit binaries.

Finally, in the 3rd phase, throw out the current memory manager in favor of
a paging VM system.

>Comments would be appreciated.
>- Guy Helmer
>  South Dakota Tech
>  BITNET: HELMER@SDNET
>  UUCP: ghelmer@loft386 (or) ...!killer!warble!loft386!ghelmer

Any comments on my comments?

Jaime
...........................................................................
: domain: jds@mimsy.umd.edu				     James da Silva
: path:   uunet!mimsy!jds