HELMER%SDNET.BITNET@vm1.nodak.edu (Guy Helmer) (12/17/88)
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. 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. Comments would be appreciated. - Guy Helmer South Dakota Tech BITNET: HELMER@SDNET UUCP: ghelmer@loft386 (or) ...!killer!warble!loft386!ghelmer
allan@dhw68k.cts.com (Alan Perry) (12/18/88)
At this point, I would be happy if Minix ran on my 386 machine at all (let
alone take advantage of all its nifty features!!).
Are there any 386 machines that Minix runs on (I know that I, the keeper
of the compatability list, should know, but the list isn't handy)?
--
--------------------------------------------------------------
alan perry UUCP: {trwrb,hplabs}!felix!dhw68k!allan
Internet: allan@dhw68k.cts.comjds@mimsy.UUCP (James da Silva) (12/19/88)
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
jds@mimsy.UUCP (James da Silva) (12/19/88)
In article <17124@dhw68k.cts.com> allan@dhw68k.cts.com (Alan Perry) writes: > >At this point, I would be happy if Minix ran on my 386 machine at all (let >alone take advantage of all its nifty features!!). > >Are there any 386 machines that Minix runs on (I know that I, the keeper >of the compatability list, should know, but the list isn't handy)? Well, it at least runs on the Intel iSBC 386-AT (yes, it's in the compatibility list). Actually, lots of people seem to have Minix working on their 386s. What Minix version are you trying, and what are the problems you're having? The only problems I've heard of with Minix specific to the 386 are the `lock nop' problem in vid_copy --- but that's ancient history, fixed in 1.2 --- and timing problems in the floppy driver. But then, 386 AT clones are subject to the same compatibility problems as all other clones, so it could be any number of things unrelated to the 386. Jaime ........................................................................... : domain: jds@mimsy.umd.edu James da Silva : path: uunet!mimsy!jds
hermit@shockeye.UUCP (Mark Buda) (12/21/88)
In article <15062@mimsy.UUCP> jds@mimsy.umd.edu (James da Silva) writes: >In article <17124@dhw68k.cts.com> allan@dhw68k.cts.com (Alan Perry) writes: >> >>Are there any 386 machines that Minix runs on (I know that I, the keeper >>of the compatability list, should know, but the list isn't handy)? > >Well, it at least runs on the Intel iSBC 386-AT (yes, it's in the >compatibility list). Actually, lots of people seem to have Minix working >on their 386s. I got both Minix 1.1 and 1.2 to work on both a Genuine IBM PC/XT with an Intel InBoard 386, and on a Fountain 386. The Fountain needed a small patch to the floppy driver; about one line of code. Just a cheap clone controller, I guess. I would be more than happy to do all of the work on a 386 version of Minix myself, if I had a 386 C compiler. It is impossible to get GNU C to compile under MS-DOS and remain sane. But I had this idea... I could get the binaries for the VAX version of GNU C, and write a VAX emulator, and use the emulator to run the VAX GCC to compile a 386 GCC to run on a VAX, and then use the emulator to run the 386 GCC to compile Minix. Am I insane? -- Mark Buda / Smart UUCP: hermit@shockeye.uucp / Phone(work):(717)299-5189 Dumb UUCP: ...rutgers!bpa!vu-vlsi!devon!shockeye!hermit I hate this $%$@%!$@%!@$%@#$@!% machine. "A little suction does wonders." - Gary Collins
brucee@runx.ips.oz (Bruce Evans) (12/27/88)
I now have Minix working well in protected mode on the 386. The main limits
are that segments are still 64K and no use is made of paging. I have some
support for 32 bit executables and a 32 bit compiler to produce these
(and itself) within the old limit of 64K text and 64K data. The 64K limit
will eventually vanish when mpx88.s and klib88.s are rewritten and
kernel/mm/fs are recompiled with 32 bit sizes.
I plan to post the changes necessary for the 16 bit protected mode system
sometime in January (after my RS232 stuff). These will provide increased
system reliability and access to lots of memory. This should be valuable
even without 32 bit sizes. The diffs may be a lot smaller than for RS232,
but my kernel diffs are now 237K (counting RS232) and I'm concerned about
separating what's needed. Also, there is a fair amount of 386 assembler
(much easier to work with than 286) which will have to be reduced to asld's
level. (Does asld even have the '&', '|' C operators? I don't think it
has #if.)
The system retains the ability to run unprotected and configures this way
automatically for 286's and 88's (apart from *wini.c). Because of this, I
haven't worried much about putting #ifdef i80386 everywhere it belongs.
The cost is 5 to 10K of unused code/data on an 88, and (very) few extra
decisions at run time based on the 'processor' variable. My debugger
(just posted) works on the protected mode and 32 bit code by switching to
real mode, limited to addresses below 1M. Apart from this, real mode is not
used so the system could be made to run 286 protected mode by modifying
the TSS structure and eliminating the 386 assembler code.
Techical details
----------------
Users run at privilege 3
Servers 1
Interrupt handlers 0
Servers could be run at privilege 0 with less interrupt latency but the
level switch gives a convenient stack frame (straight into proc table - less
dangerous than on 88). I have an out of date version which does task
switching. This is superficially nicer, perhaps not requiring any assembler
in interrupt handlers, but what I wrote came out larger and slower (context
switch 10-20% slower. Protected mode switching is already 10-20% slower).
Minix centralizes the task switching, unlike the hardware.
The process table has extra entries for FSREG, GSREG and all register slots
are expanded to longs. The process table also holds the LDT register
(constant after init) and a 2 entry LDT to hold segment descriptors for code
and data.
New kernel files:
const386.h - addendum to const.h
pm.c - mainly initialization of GDT entries and interrupt handler stubs (asm)
Changed kernel files:
mpx88.s - 8088 version already rewritten, new savep and restartp
klib88.s - everywhere it uses physical addresses redone directly (flat 4G seg)
system.c - fork and exec need to build segment descriptors. This is the main
dynamic difference and is "simple".
proc.c - "unnecessary" large changes supported by mpx88.s
clock.c - "unnecessary" small changes supported by mpx88.s
others - minor changes in const.h, proc.h, type.h, dmp.c, main.c ...
Changed mm/fs/lib files:
A new magic number in the exec header for 386 executables has to be fetched
and passed to the kernel so the 32-bit bit can be set if required. Both
mm and fs have to ask kernel about memory allocation.
Bruce Evans
Internet: brucee@runx.ips.oz.au UUCP: uunet!runx.ips.oz.au!brucee