MDOELL%DOSUNI1.BITNET@cunyvm.cuny.edu (Magnus Doell) (10/02/90)
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 <a.out.h> 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. <mdoell@dosuni1.bitnet>
fwb@hpfcdj.HP.COM (William Bennett) (10/06/90)
I been trying to follow this "Bruce stuff", but I have been unable to figure out where to get the 386 protected mode stuff. Could you please enlight us where one can find such stuff? I am at 1.3 and the path to 1.5.10 seem like a monumental task. I wonder if those GNU guys are catching up with MINIX yet? "Thanks for your support" Frank Bennett
cracraft@ai.mit.edu (10/07/90)
I've had a bad experience with the 386 kernel and associated utilities (cppmake, db). cppmake simply would not build. Under __STDC__ #ifdef's the inclusion of <varargs.h> wasn't supported by Minix 1.5. Commenting that out resulted in numerous other errors such as "wait_t" as an undefined typedef and various completely opaque errors. And the one little comment "unless everything is in place the 386 binaries (presumably bcc, as, sc, ld? -- please state!) won't work". I feel the documentation should plainly state so there's no room for doubt "These four utilities are 32 bit mode (assuming 32 bit distribution included) and will not run until the changes made in mx386/README have been made." or something like this. The entire 386 kernel installation notes ran a total of a page or two and really lacked depth. Separate programs like cppmake had their own opaque documentation and no "What if when there's an error" section. For an installation of this magnitude of a change to an OS, there should be very precise notes about exactly what steps to follow, AND the author should have tried it already on various configurations to ensure that it works. To repeat: installation of Evans' 386 kernel with Chew's cppmake failed miserably on a Minix 1.5 (IBM PC AT clone). It was very disappointing. Stuart
cjeffery@cs.arizona.edu (Clinton Jeffery) (10/08/90)
From article <32696@nigel.ee.udel.edu>, by cracraft@ai.mit.edu: > ...Stuart trashes all over on Bruce and Earl, winding up with: > > To repeat: installation of Evans' 386 kernel with Chew's cppmake > failed miserably on a Minix 1.5 (IBM PC AT clone). It was very > disappointing. > > Stuart I haven't even looked at Bruce's kernel, but I think your complaint is ridiculous. This is volunteer work, done by a rag-tag fleet on a lonely quest for a shining planet called...Minix. To criticize them for not producing an "upgrade" up to your standards ("an idiot should be able to get this to work on arbitrary hardware before you post it") is absurd. Since they can't distribute a complete, working set of disks thanks to Andy's decision (long, long ago) to SELL the disks through Prentice-Hall, you can't really blame Bruce or Earl for the difficulties in applying their modifications. Maybe Andy should persuade Prentice-Hall to SELL a version of Minix with Bruce's 386 code already in place, for people like Stuart... My apologies to everyone I've offended (I'm sure there are dozens...) -- | Clint Jeffery, U. of Arizona Dept. of Computer Science | cjeffery@cs.arizona.edu -or- {noao allegra}!arizona!cjeffery --
tvf@cci632.UUCP (Tom Frauenhofer) (10/08/90)
In article <32696@nigel.ee.udel.edu> cracraft@ai.mit.edu writes: >I've had a bad experience with the 386 kernel and associated >utilities (cppmake, db). I'm "half way" through this process right now. It is NOT for the faint of heart. > cppmake simply would not build. Under You have to work over the code a little bit. That is clearly spelled out in all of the README's for all of the pieces. >And the one little comment >"unless everything is in place the 386 binaries (presumably >bcc, as, sc, ld? -- please state!) won't work". Again, OS building is NOT for the faint of heart. This is an OS that is under development, probably at alpha level of release, maybe beta (no, pretty much alpha). >I feel the >documentation should plainly state so there's no room for >doubt "These four utilities are 32 bit mode (assuming 32 >bit distribution included) and will not run until the >changes made in mx386/README have been made." or something >like this. Actually, I thought this was pretty clear. Granted, I took a lot of time reading over the code and stuff to make sure that I knew what I was doing, and I'm only doing a piece here, a bit there, but I'm in no rush. Besides, Bruce is on the network, and he has been more than willing to sift through comments/problems about this process (including trying to figure out his problem when the reason was actually my incorrect set-up because I rushed one piece - this is the real cost of support, the wasted time). And besides, you do get the source to bcc.c so you can have sc/as/ld where you want them, if you don't like /local/bin. BTW, I think he was referring to the sources and libraries for building the 32-bit kernel/mm/fs/etc. >The entire 386 kernel installation notes ran a total of >a page or two and really lacked depth. Separate programs like >cppmake had their own opaque documentation and no "What if >when there's an error" section. Actually, if I have time, I hope to flesh out some of this documentation a little more. I will give you this - if Earl Chew created cppmake, then he did slack off a little on the documentation. His documentation for other software he's developed has been excellent (e.g., shoelace). >For an installation of this magnitude of a change to an OS, there >should be very precise notes about exactly what steps to follow, AND >the author should have tried it already on various configurations to >ensure that it works. Even the commercial System V Unix vendors don't have the finances/time to do this (or so they claim, anyway), and they get paid for doing it. I don't believe that either Bruce or Earl get a dime for their Minix stuff (please show us a payslip if I'm wrong, guys! :-) ). In fact, that's why I've decided to get out of the commercial System V Unix world for my home system - in my experience, support was not all that good. Now I've been on the support side of the phone, and let me tell you all I can appreciate how hard a job it is. The level of support you get is dependent on two factors - the investment that a company puts into it, and the desire of the support personnel to make it work (even if the company doesn't give them what they need). Prentice-Hall puts nada into Minix support, and I don't necessarily blame them. We're support, folks, every one of us who decides that we're going to run Minix on our home systems for whatever reason. If you can pony up to that, fine. If you can't, then I suggest you get another OS for your system. For what Bruce's package lacks in documentation, it is more than made up by his availability. I for one appreciate that. >To repeat: installation of Evans' 386 kernel with Chew's cppmake >failed miserably on a Minix 1.5 (IBM PC AT clone). It was very >disappointing. I'm sorry you had a hard time. I think you expected too much, namely a "drop it in and it works" system. That was one thing that was very clear in the documentation - this isn't an appliance OS. -- Thomas V. Frauenhofer, WA2YYW ccicpg!cci632!tvf@uunet.uu.net tvf1477@ma.isc.rit.edu "Time's a-wasting, speedy!" - the turtle (to Bugs Bunny)
chuck@eng.umd.edu (Chuck Harris) (10/08/90)
In article <32696@nigel.ee.udel.edu> cracraft@ai.mit.edu writes: > >I've had a bad experience with the 386 kernel and associated ... >The entire 386 kernel installation notes ran a total of >a page or two and really lacked depth. Separate programs like >cppmake had their own opaque documentation and no "What if >when there's an error" section. > >For an installation of this magnitude of a change to an OS, there >should be very precise notes about exactly what steps to follow, AND >the author should have tried it already on various configurations to >ensure that it works. > >To repeat: installation of Evans' 386 kernel with Chew's cppmake >failed miserably on a Minix 1.5 (IBM PC AT clone). It was very >disappointing. > >Stuart Gosh Stuart, how about writing these notes and doing these tests yourself, so that the rest of us won't fall into the same traps that you did? Bruce volunteered his time to make the 386 kernel, and to the best of my knowledge is in no material way compensated for his work by Andy or PH. Save your harsh critisism for manufacturers to whom you pay for services, and instead thank Bruce for giving you such a nice toy. And offer to him your services towards making it a better toy. (obtw, I in no way mean to belittle Bruce's effort by calling his 386 kernel a "toy" I somehow think he will understand what I mean) Chuck Harris chuck@eng.umd.edu
rdc30med@nmrdc1.nmrdc.nnmc.navy.mil (LCDR Michael E. Dobson) (10/09/90)
In article <32696@nigel.ee.udel.edu> cracraft@ai.mit.edu writes: > >I've had a bad experience with the 386 kernel and associated >utilities (cppmake, db). cppmake simply would not build. Under >__STDC__ #ifdef's the inclusion of <varargs.h> wasn't supported >by Minix 1.5. Commenting that out resulted in numerous >other errors such as "wait_t" as an undefined typedef and Uhhmm, did you try grep'ing /usr/include to find where they were defined? That's a trick anyone porting or installing software should know. >The entire 386 kernel installation notes ran a total of >a page or two and really lacked depth. Are you sure? I have almost a dozen or so pages of various notes, READMEs, bugs, etc. Taken together, they provide quite a bit of information. [ more whinning deleted] >To repeat: installation of Evans' 386 kernel with Chew's cppmake >failed miserably on a Minix 1.5 (IBM PC AT clone). It was very >disappointing. > Well it worked very well for me. I never did get ccpmake to work, but it wasn't very hard to create different flavors of makefiles for ACK, bcc-16 and bcc-32. The library installation was a breeze thanks to the EXCELLENT documentation and the makelib scripts. I was able to build a 32-bit system on a '286 as well as on a '386 with only 2 Meg of RAM. I installed not only the current mnx386_1.1, but Bruce's first version that was "released". As other respondents have mentioned, Bruce was very responsive to e-mail requests when I got stuck (due almost always to my own stupidity). I would like to point out that I am not a CS sutdent, nor a software engineer. I can barely read a C program and still haven't figured out how to change passing a struct to a function to passing a pointer to the struct into the function, but I found adding the 386 changes to the kernel far easier that any of the upgrades (I started with 1.1). So in summary, contrary to Stuart's experience, it isn't that hard to build Minix-386 with the tools Bruce has so graciously provided with more than a little help from Earl. However, if you had trouble with the upgrades, then perhaps you aren't ready to tackle this project. -- Mike Dobson, Sys Admin for | Internet: rdc30med@nmrdc1.nmrdc.nnmc.navy.mil nmrdc1.nmrdc.nnmc.navy.mil | UUCP: ...uunet!mimsy!nmrdc1!rdc30med AT&T 3B2/600G Sys V R 3.2.2 | BITNET: dobson@usuhsb.bitnet WIN/TCP for 3B2 | MCI-Mail: 377-2719 or 0003772719@mcimail.com