ast@botter.UUCP (02/01/87)
I just got back from D.C. and Palo Alto. There was lots of news and mail. In this note I will respond to those issues that I think may be of interest to more people than just the person who brought it up. There has been a lot of discussion about somewhat metaphysical issues so far, but as more people begin looking at the code, that should change. P-H has the diskettes and tape in production now. It shouldn't be more than a couple of weeks now. When a big company does something on a large scale, it takes longer than a single individual doing it once. You wouldn't believe how many iterations it took just to get the diskette labels right, even though I gave them the exact text in typewritten form. I gave a paper on MINIX at UNIFORUM and a BOF session at USENIX. The former was attended by maybe 100 people belonging to the three piece suit crowd. The latter was well attended by a crowd that would probably be more inclined toward tee shirts and sandals if there hadn't been 15 inches of snow on the ground. I also gave a talk on MINIX at the Computer Literacy bookshop in Silicon Valley. The owner of that store, Dan Doernberg, called up P-H so many times that he actually convinced them to let him stock the diskettes. Call them at (408) 730-9955 for more info. I don't believe any other store is planning to stock them, but you can order the software by mail using the card in the back of the book. Things may change in a couple of months. P-H is slowly starting to think about having other stores stock the software. I'll discuss this when the dust settles. Here are some comments in no particular order. I tested the 1.2M diskettes on a few AT clones at the UNIFORUM show. The results are listed below. Machine Did MINIX run? Hard disk ok? ------- -------------- ------------- Epson Equity 3 yes yes BIOS silent partner yes yes Honeywell AP yes yes Unisys Micro IT yes yes NCR PC8 yes see note 1 below IBM PC-AT @6MHz yes yes IBM PC-AT @8MHz yes no IBM XT-286 yes no Televideo Telenix 286 yes no, but see note 2 below Compaq portable 2 no ? Compaq 386 no ? Note 1: MINIX was consistently able to read the first 80 blocks, but consistently got errors after that. I think this means that the machine uses the same controller as the 6MHz AT, but the drive is formatted differently, or the controller can't handle implied seeks or something like that. The driver will require some patching for this machine, but I suspect the patching will be simple once it is figured out what happened. Note 2: The machine I tested didn't have Televideo's standard disk. Since the person at the show was only a salesperson, he didn't know what kind it did have. Nor did he know what kind they normally have. Nor did he know why this one didn't have what the other ones have. In fact there were quite a few additional things about the machine absent from his data base. I was surprised (chagrined?) that IBM changed disk controller's between the 6 and 8 MHz versions. There is certainly no technical reason for this, as the controller they use on the 6 MHz AT also works on 8 MHz machines. They also changed the keyboard between the models. The 6 MHz version has a return key you can see with the naked eye. I guess they perceived this as being too clonable, so they got rid of it on the 8 MHz version. I don't know if the XT-286 machine uses the same disk controller as the XT, 6 MHz AT, 8 MHz AT, or yet a fourth one. Amoeba and MINIX are unrelated projects. Amoeba is a research project in building distributed operating systems. It is in the same general league as the V project at Stanford and the Mach project at CMU, but it differs from both of these in many technical ways. See my paper in the Dec. 85 Computing Surveys for a brief discussion of Amoeba and references to published papers. The ACK compiler presently has front ends for C, Pascal, BASIC, Modula 2, and Occam, as well as a subset of ADA and various other languages. It has back ends for the 8080, 8088, Z80, Z8000, 6800, 68000, 6502, 32016, PDP-11, VAX, but not the 370. There is also a highly optimizing back end for the 68020 that was just finished. Not all of this stuff is available yet. Ask UniPress or Transmediair for details. The C to 8088 compiler supplied with MINIX is not mediocre, at least in my opinion. What I actually said at the BOF is that the code quality is about 15% worse than the PC-IX compiler produces. The binaries provided with MINIX were compiled with the PC-IX compiler, so if you recompile anything with the MINIX compiler, it will be about 15% larger. I have made a few quick comparisons of the MINIX compiler vs. some MS-DOS compilers, and the MINIX compiler seems to be in the middle. Some are better and some are worse. The main problem with the MINIX compiler is that it doesn't use register variables very much. MINIX supports 64K of program space and 64K of data space, for a total of 128K. The stack register (SS) is completely useless because if you had a third 64K segment, how could you tell if a 16-bit pointer pointed to data space or stack space? Thus the data segment and stack segment share the same 64K space. If you cross compile using PC-IX or the C86 compiler, you can have a maximum of 128K. With the MINIX compiler the maximum is 64K, because I didn't have time to figure out how to make the assembler produce separate I & D space, although in theory it should be able to. That may get fixed eventually. Minor bugs have turned up in doswrite and ar. I'll post fixes later. In general, it is ok to post individual files that you have debugged. In many cases a diff listing will be more appropriate because most net traffic uses dial up phone lines which may be free to you, but are not free to the organizations footing the bills. If you find 6 bugs in a 50 line file, it is reasonable to post the whole corrected file. If you find 1 bug in a 1000 line file, a diff listing is more appropriate. Although I have said this several times before, the mail and news indicate that a number of people haven't heard it. MINIX is copyrighted. It is not public domain. However, the copyright owner, P-H, has agreed that professors can make copies for students, and that individuals can make a couple of copies of the sources or binaries for noncommercial use. Other copying requires permission, just as all copies of Lotus, Turbo Pascal, etc. do. Posting of small MINIX source files is ok if you have made useful improvements or fixed bugs. The system calls missing from h/callnr.h fall into two categories: those call numbers that were unused in V7, and those calls that I didn't implement. The latter include ptrace, mpx, phys, pkon, pkoff, nice, lock, and acct, as I recall. The MINIX numbering is the same as V7. This information is not secret, incidentally. You can buy the V7 manual in a bookstore, as AT&T had it published by Holt, Rinehart, and Winston (ISBN 0-03-061742-1). The Atari port is being done by people at Philips in Holland. I hesitate to give their addresses because I would rather that they write code than answer mail. For people interested in porting MINIX to other 68000s (Amiga, Macintosh and so on), I would suggest FIRST reading the book and code carefully, THEN running to the terminal. By that time the Atari port may be pretty far along and you can use it as a base, instead of the 8088 version. While on the subject of porting MINIX, a variety of people have sent me mail inquiring about who is doing ports to what. I would suggest that people who have time and interest in doing ports post messages to this group announcing themselves and perhaps saying a bit about their backgrounds and expertise. The Amiga, Macintosh, 286, 386, 68020, and other groups can then try to divide the work up by mail. There is something to be said for having more than one group working on each CPU, in case one of them has to give up for whatever reason. Once the 68000 specific stuff has been finished, ports to 68000 based CPUs will mostly require writing drivers. As a rule, you probably won't be able to use the ROM BIOS for disk or terminal input, because they rarely support interrupts. It may be possible to use the ROM BIOS for terminal output. I didn't go that route on the PC because the BIOS is awful. On a color display the screen flickers as it scrolls because the guys who wrote the BIOS didn't understand how to program the 6845 properly. MINIX works fine on either a mono or color display, with no flicker on either. There is some kind of problem with the EGA card. The screen goes blank periodically and then comes back in a peculiar way. My best guess is that it has something to do with driver thinking the card has 4K RAM when it actually has 256K. When an EGA owner gets MINIX, please see if you can figure out what is going on. I don't think this fix will be difficult, but I don't know the EGA card well. There has been a lot of discussion about XINU and GNU here. Some people have naively assumed they can put the GNU utilities on top of MINIX. I wouldn't count on it. First of all, they are not likely to restrict themselves to the V7 system calls (although all programmers should really do this to ensure portability between 4.3 and System V). Second, there is likely to be a problem with program size. MINIX only supports 64K + 64K as discussed above. I don't remember if XINU has any utilities with it, but in any case, the system calls supported by XINU are quite different from UNIX. I don't expect either of these systems to have much, if anything, that we can use. Which brings us to the next topic. As people get the diskettes and start running the system, no doubt many people will discover that their favorite program is missing. Uucp, mail, news, and networking in general certainly are conspicuously missing. If anyone knows of public domain versions of these or other programs that are missing, posting information about them would be nice. Even nicer would be tracking them down and modifying them to run on MINIX, and then posting them. Before starting to rewrite something from scratch, I would suggest posting a query to see who else is doing what. Needless to say, do not post any copyrighted material of any kind without permission of the copyright owner. Diff listings probably aren't legal either since they contain the original lines and the changed lines, and you can't publish the original lines. If you find errors in the book or code, please report them. If they are significant, post them, but in any event, send me mail. If your router still uses source routing, send mail to: ...!seismo!mcvax!vu44!minix. Incidentally, seismo definitely knows about the nl domain. Several people have suggested setting up subgroups such as comp.os.minix.amiga, comp.os.minix.bugs, etc. I think such discussions are premature. Groups are normally split only when the volume of traffic warrants it. For the time being, just choose your subject line as carefully as possible. If the subject is "Amiga port" or "Bug in ar.c" people will be able to figure out whether they are interested or not. One area that is probably going to be chaos is what happens when dozens of people start making incompatible changes to the code. One thing that would help a little is to use the net to find guinea pigs to test your changes before making them widely known. This may improve quality a little, but I can't see any reasonable way of co-ordinating things. Maybe if we are really lucky, some changes will become so popular that everyone adopts them, and others will vanish from lack of interest. One problem that particularly worries me is this. At present there is really only one version of the code. Dynamically it figures out if it is has a color or mono machine, an IBM or Olivetti keyboard, an 8088 or a 80286 CPU, a 360K or a 1.2M diskette, etc. If someone discovers problems on the XYZ clone and puts in special code to get around it, that code may not work on "normal" machines, so we then get two versions. If it is possible and not too difficult, it is much better to dynamically determine that the current machine is different, and set some flag. For example, in the file kernel/glo.h there are now declarations: int olivetti; int pc_at; which are set to TRUE or FALSE (1 and 0, respectively) depending on whether the machine has an Olivetti style keyboard or an 80286 CPU. If the EGA board turns out to require some nonstandard treatment, it probably would be a good idea to dynamically discover that an EGA board is present during system initialization (in this case in kernel/tty.c), and add a flag to kernel/glo.h that would be set to TRUE for EGA boards. If there is no way to dynamically determine that you are faced with an EGA board or a Southern Analog disk controller or whatever, at least #ifdef the special code in a consistent way. One small request on my part. I would appreciate it if people changing the code would stick to the programming style of the file they are changing in terms of layout, indentation, where the curly braces go, etc. Please do this even if your normal style is different. It is much nicer for subsequent readers if the whole file indents 2 spaces for the body of a function, rather than having all of it indent 2 spaces except the 10 lines you added, which use 1 tab stop or some other convention. I mention this topic because the layout of the code I wrote is reasonably uniform in terms of spacing, placement and style of comments, etc., and it would be nice to keep it that way. Andy Tanenbaum (minix@cs.vu.nl)
diamant@hpfclp.UUCP (02/03/87)
> MINIX supports 64K of program space and 64K of data space, for a total of > 128K. > With the MINIX compiler the maximum is 64K, because I > didn't have time to figure out how to make the assembler produce separate > I & D space, although in theory it should be able to. That may get fixed > eventually. Given the 64K limit on the current MINIX compiler, what is the status of self-hosting MINIX? Earlier you claimed that the system can compile itself. Someone else in this group suggested that this may not be true because of size limitations. I understand that even if it works, you won't get the same size executables, but is it even possible (for the entire system)? > However, the copyright owner, P-H, has agreed that professors > can make copies for students, and that individuals can make a couple of copies > of the sources or binaries for noncommercial use. I read the copyright notice in the book (regarding the software, not the book itself), and I saw no mention of "a couple of copies." It seems to indicate that all non-commercial/educational use is O.K. via copies. Am I misreading it or is that really O.K.? > > Andy Tanenbaum (minix@cs.vu.nl) John Diamant SCO UUCP: {hplabs,hpfcla}!hpfclp!diamant Hewlett Packard Co. ARPA Internet: diamant%hpfclp@hplabs.HP.COM Fort Collins, CO
thomps@gitpyr.UUCP (02/05/87)
In article <9490001@hpfclp.HP.COM>, diamant@hpfclp.HP.COM (John Diamant) writes: > Given the 64K limit on the current MINIX compiler, what is the status of > self-hosting MINIX? Earlier you claimed that the system can compile > itself. Someone else in this group suggested that this may not be true > because of size limitations. I understand that even if it works, you won't > get the same size executables, but is it even possible (for the entire system)? This answer is based on the book. Andy can correct me if I've misinterpreted something. The MINIX OS can be recompiled using the MINIX system even given the 64K limit. It is possible because MINIX is actually three separate programs. 1. Process management and I/O tasks. (these are functionally separate but linked in the same image to facilitate porting to processors that require all I/O instructions to be executed in protected mode) 2. Memory manager. It runs at a level above process management and would not need to run in protected mode. 3. File system. ditto 2 Even though MINIX may be rebuilt using the C compiler provided, it was actually developed under PC/IX which is IBM's PC UNIX. I would not be at all suprised if the MINIX compiler produces poorer code. My experience with academic compiler projects and ACK (Amsterdam Compiler Kit) on which the MINIX compiler is based would lead me to believe that efficiency was probably not one of their top priorities. The source to the compiler will be sold for 99.95 but god knows what it will look like having come out of ACK. -- Ken Thompson Phone : (404) 894-7089 Georgia Tech Research Institute Georgia Insitute of Technology, Atlanta Georgia, 30332 ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!thomps