Path: utzoo!attcan!uunet!wuarchive!udel!mmdf From: MDOELL%DOSUNI1.BITNET@cunyvm.cuny.edu (Magnus Doell) Newsgroups: comp.os.minix Subject: extension to Bruce"s 386 kernel and MINIX Message-ID: <32039@nigel.ee.udel.edu> Date: 1 Oct 90 19:28:41 GMT Sender: mmdf@ee.udel.edu Lines: 71 Hi! A few weeks ago, I got Bruce's 386 extension to MINIX-PC 1.5. While installing this software, I noticed that Bruce uses two kinds of directory structures, one for 386 OS and one for ordinary 86 OS, which he moved around on switching the OS. I also noticed, that I don't want to have all binaries etc. doubled, so I have a close look at the sources and on some 386 literature and found, that the 386 should be able to run 86 programs. There are some problems, which must be solved before this: 1. The kernel build descriptors for 32-bit modes as default, this shouldn't be on ordinary 86 processes. As mm is the only process knowing about the header of a program, it should tell the kernel the new processes default sizes on execing, so that the kernel could change the processes LDTs. 2. The mm should recognize 86 programs by the header and let them pass the test in read_header() (could anybody tell me, why mm doesn't use to detect the correct header? I have changed this in my version of mm!). 3. As ordinary 86 processes won't access the 32-bit registers, there might be junk in the upper 16-bit half of the registers on system calls through INT SYSVEC. But as 86 processes traps to other vectors on sytem calls, this could easily masked out within _p_s_call in mpx386.x 4. There is a C-compiler dependency in the OS given by defining the message structure as union of structures holding int's, char *'s and (void *)()'s This results in different sizes and offsets for messages on 86 processes vs. 386 processes. The kernel will copy more than the message structure for 86 processes, which might conflict (or not), but when mm or fs interprets the messages with their thought of offsets and sizes (they are 386 procs) they won't get what the 86 process wants them to get! This problem could be solved within the message copy, if the kernel doesn't copy messages as it, but translate them from one format into the other. 5. The same problem is duplicated within mm in routine patch_ptr() called while execing, as it interprets the stack it is copying to be int's and char *'s So mm should also do this job depending on the old processes size and the newly execed processes size. 6. A problem coming from different register sizes, like problem 3, is given within the signal generation. mm checks the processes stack, whether it is great enough to hold a signal stackframe with constant size (different in the two modes), whereas the kernel pushes the signal stackframe onto the processes stack, containing a return address and a signal number. Both objects have different sizes in the different modes. There may be more places, where problems can happen, but I couldn't see them today - any hints. Yesterday I have fixed the first 3 problems by patching kernel/mpx386.x, kernel/system.c and mm/exec.c and tried these fixes with some assembler routines avoiding the problems 4 to 6 by not installing a signal handler, not using the arguments (so I couldn't use crtso.s) and managing messages with 386-sizes and -offsets explicitly. I've used asld for building the executables (so I am sure to generate 16-bit codes) and standard MINIX cc to precompile some simple C-programs (patching the assembler output before asld'ing them with special header and library). This test-suite checks exit-, read- and write-system calls and runs perfectly with the patched 386 OS. Now, anybody interest (especially you, Bruce)? Should I go further and post the results/patches? Should this make it "official", so that there is a binary compatibility between the 386 MINIX-PC OS and 86 MINIX-PC programs (at least optional)? Ma.D.