mth@ihnp3.UUCP (01/30/87)
In a recent article Dr. Tanenbaum stated that MINIX ran OK on 80% of clones tested. Is it possible to find out which clones constituted these groups? Or at least which were in the 20% that failed? I'm assumming that the failures were due to hardware differences normally hidden by BIOS, however, it would be helpful to know what the failure modes are. This would be very helpful for us *clone folks*. ADVthanksANCE.
john@moncol.UUCP (02/02/87)
In article <275@ihnp3.UUCP> mth@ihnp3.UUCP writes: >In a recent article Dr. Tanenbaum stated that MINIX ran OK on >80% of clones tested. Is it possible to find out which clones >constituted these groups? Or at least which were in the 20% >that failed? I'm assumming that the failures were due to >hardware differences normally hidden by BIOS, however, it would >be helpful to know what the failure modes are. This would be >very helpful for us *clone folks*. First of all, my apologies to those who'd rather read good, technical stuff on MINIX rather that yet another "will MINIX run on my machine" posting. I'll try to be brief. Does anybody know if MINIX will run on the Tandy 1000? The reason I ask is that the 1000 is not your usual IBM-compatable. From what I can tell, it meets Dr. Tanenbaum's criteria of having the correct floppy disk controller and video controll chips. It does, however, have two unusual features which I am worried about: 1) Non-parity-checked memory 2) No dedicated video ram on a video card. Rather, the BIOS steals the top 16K of normal ram for this purpose. I'd check the book myself if only my copy would arrive. (That's why this posting...) Thanks in advance... -- Name: John Ruschmeyer US Mail: Monmouth College, W. Long Branch, NJ 07764 Phone: (201) 571-3557 UUCP: ...!vax135!petsd!moncol!john ...!princeton!moncol!john ...!pesnta!moncol!john Is this article <adjective> or what???
hrh@well.UUCP (02/06/87)
My apologies if this is a dumb question, by why the design decision to make MINIX so hardware-dependant. Why wasn't the BIOS used? Does the BIOS not provide enough functionality? If the problem is just speed, why not write a slower version for those of us whose chips don't have the right pedigree? The hardware dependance strikes at one of the basic tentents of UNIX philosophy. -- The opinions expressed are my own, but you're welcome to share them. Harry Henderson (freelance technical editor/writer).
rmtodd@uokmax.UUCP (02/08/87)
In article <2529@well.UUCP>, hrh@well.UUCP (Harry Henderson) writes: > My apologies if this is a dumb question, by why the design decision to > make MINIX so hardware-dependant. Why wasn't the BIOS used? Does the > BIOS not provide enough functionality? If the problem is just speed, > why not write a slower version for those of us whose chips don't have > the right pedigree? The hardware dependance strikes at one of the > basic tentents of UNIX philosophy. It's not a dumb question. The problem is that the people who wrote the ROM BIOSes for the clone motherboards, the HD controllers, etc. did not write them with multitasking in mind. Thus the BIOS code is not reentrant -- multiple tasks cannot call the BIOS without mass confusion arising as task 2's call writes on top of the variables set by task 1's call. You could try to set it up so that only one task at a time can access the BIOS and all the rest block. Wendin's PCUNIX does this. In fact, if I remember correctly, they found that you couldn't even safely switch out of the current task if it was executing BIOS code. It does rather interesting things to the system performance. For these reasons, if you want really good multitasking performance, don't use the ROM BIOS. I've heard that PC/IX, like MINIX, is picky about what hard drives it'll use for the same reason. I suspect XENIX acts the same way. On a (somewhat related) subject, does anyone know just what *is* the type of controller MINIX expects? A check inside my machine shows Western Digital chips (WD1010, WD1015, and WD1020, I think), and a ROM HD BIOS with "Copyright (c) 1985 Western Digital". I'd like to know if this is the kind that works. As for violating "the tenets of the UNIX philosophy", all UNIX systems have device-dependent driver code. The UNIX philosophy just puts all the mess in a small section of the code, leaving the rest relatively portable. -------------------------------------------------------------------------- Richard Todd USSnail:820 Annie Court,Norman OK 73069 UUCP: {allegra!cbosgd|ihnp4}!okstate!uokmax!rmtodd
philip@axis.UUCP (02/08/87)
In article <2529@well.UUCP>, hrh@well.UUCP writes: > My apologies if this is a dumb question, by why the design decision to > make MINIX so hardware-dependant. Why wasn't the BIOS used? Does the > BIOS not provide enough functionality? If the problem is just speed, > why not write a slower version for those of us whose chips don't have > the right pedigree? The hardware dependance strikes at one of the > basic tentents of UNIX philosophy. This is explained in the book. It is also almost certainly explaine if you have ever tried to use BIOS calls yourself - certain of them can only be used in certain circumstances, and others leave the machine in an unstable state, which must be rectified by making another BIOS call (with parameters set so that it does nothing) to make the machine stable again .... But, the most important reason (as given in the book) is that the BIOS calls do not use interrupts. So, when your shell does a read(), BIOS loops on the status bit of the serial line UART (for example), and the machine effectively stops for all other processes. BIOS/MSDOS/PCDOS and the rest realy are single process machines, and in general, no part of them is useful in a 'real' computing environment. MINIX does actually make one BIOS call - at startup, to see if the machine has a mono or colour board installed. It also relies upon the BIOS chip to load the bootstrap program. Philip
ron@unirot.UUCP (02/08/87)
In article <447@uokmax.UUCP>, rmtodd@uokmax.UUCP (Richard Michael Todd) writes: > In article <2529@well.UUCP>, hrh@well.UUCP (Harry Henderson) writes: > > My apologies if this is a dumb question, by why the design decision to > > make MINIX so hardware-dependant. Why wasn't the BIOS used? Does the > > BIOS not provide enough functionality? If the problem is just speed, > It's not a dumb question. > The problem is that the people who wrote the ROM BIOSes for the clone > motherboards, the HD controllers, etc. did not write them with multitasking > in mind. Thus the BIOS code is not reentrant -- multiple tasks cannot The MINIX (or UNIX for that matter) disk drivers aren't reentrant either. They are queue driven. Essentially, they sit there reading from a queue, one I/O operation at a time, executing them sequentially. I see no reason why a BIOS driven driver wouldn't suffice here. -Ron
ddl@husc6.UUCP (02/09/87)
In article <172@axis.UUCP>, philip@axis.UUCP writes: > This is explained in the book. > It is also almost certainly explaine if you have ever tried to use > BIOS calls yourself - certain of them can only be used in certain > circumstances, and others leave the machine in an unstable state, which > must be rectified by making another BIOS call (with parameters set so that > it does nothing) to make the machine stable again .... I use the BIOS calls a great deal and I have never encountered problems with the machine being left in an unstable state. Can you give a specific example? > But, the most important reason (as given in the book) is that the BIOS > calls do not use interrupts. So, when your shell does a read(), BIOS > loops on the status bit of the serial line UART (for example), and the > machine effectively stops for all other processes. This is plain wrong. The IBM PC keyboard is interrupt-driven. Int 9 is used, if you are interested. Characters are stored in a FIFO buffer. The get-a-character call does, indeed, loop waiting for a character to appear in the FIFO buffer; however, there is a get-status call which will not hang. Furthermore, it is trivial to catch int 9 and use it as a cue to ckeck for keyboard activity. The combination gives you an interrupting keyboard. > BIOS/MSDOS/PCDOS and the rest realy are single process machines, > and in general, no part of them is useful in a 'real' computing > environment. I use the BIOS in OS for keyboard and disk i/o. It works fine. It runs on clones because they all emulate the BIOS interface. I like to think of it as a "'real' computing environment." Well, as real as you can get on an 8088. Dan Lanciani ddl@harvard.*
robert@gitpyr.UUCP (02/10/87)
>ddl@husc6.UUCP (Dan Lanciani) (ddl@husc6.UUCP, <1192@husc6.UUCP>): > In article <172@axis.UUCP>, philip@axis.UUCP writes: > > But, the most important reason (as given in the book) is that the BIOS > > calls do not use interrupts. > This is plain wrong. The IBM PC keyboard is interrupt-driven. > Int 9 is used, if you are interested. It's not plain wrong. It's halfway wrong. The keyboard, yes, is interrupt driven, along with the disk drivers. However, the async ports are not. Ever try to write a communication program that uses the bios calls to do async port i/o? You can't get better than 1200 baud without dropping characters. To handle high baud rates you have to write your own interrupt handler. robert -- Robert Viduya robert@pyr.ocs.gatech.edu Office of Computing Services (404) 894-4660 Georgia Institute of Technology Atlanta, Georgia 30332
thomps@gitpyr.UUCP (02/10/87)
In article <1192@husc6.UUCP>, ddl@husc6.UUCP (Dan Lanciani) writes: > In article <172@axis.UUCP>, philip@axis.UUCP writes: > > > But, the most important reason (as given in the book) is that the BIOS > > calls do not use interrupts. So, when your shell does a read(), BIOS > > loops on the status bit of the serial line UART (for example), and the > > machine effectively stops for all other processes. > > This is plain wrong. The IBM PC keyboard is interrupt-driven. > Int 9 is used, if you are interested. Characters are stored in a FIFO > buffer. The get-a-character call does, indeed, loop waiting for a > character to appear in the FIFO buffer; however, there is a get-status > call which will not hang. Furthermore, it is trivial to catch int 9 > and use it as a cue to ckeck for keyboard activity. The combination > gives you an interrupting keyboard. > I believe Dan, Phil and Andy T. are talking about the same thing here. The keyboard interrupt is supplied by the hardware and has nothing to do with BIOS. What BIOS supplies is a keyboard driver or interrupt handler which catches the interrupt and places the code for the depressed key in the keyboard buffer. BIOS provides calls to get information out of the buffer, find out if anything is in it etc. However, if I catch the int 9 directly from the hardware (as Dan suggests) and use my own interrupt handling routine or driver and am no longer using BIOS. I am sure that this is what MINIX's keyboard driver does. Dan's argument really says that the BIOS is does not do the kind of interrupt I/O that a multitasking operating system needs because if we let the BIOS keyboard driver handle the keyboard interrupt, the process waiting for the character will never know its there unless it checks explicitly. Therefore, the BIOS driver must be replaced with another one that will signal the OS when a character arrives. By the way, if hardware documentation is available it may not be that difficult to add device drivers to MINIX to support clones that are not 100% hardware compatible with the IBM PC. -- Ken Thompson (No not that Ken Thompson) Georgia Tech Research Institute Georgia Insitute of Technology, Atlanta Georgia, 30332 ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!thomps
ddl@husc6.UUCP (02/10/87)
In article <3071@gitpyr.gatech.EDU>, thomps@gitpyr.gatech.EDU (Ken Thompson) writes: > I believe Dan, Phil and Andy T. are talking about the same thing > here. The keyboard interrupt is supplied by the hardware and has > nothing to do with BIOS. What BIOS supplies is a keyboard driver > or interrupt handler which catches the interrupt and places the > code for the depressed key in the keyboard buffer. BIOS provides > calls to get information out of the buffer, find out if anything > is in it etc. However, if I catch the int 9 directly from the > hardware (as Dan suggests) and use my own interrupt handling routine or driver > and am no longer using BIOS. I am sure that this is what MINIX's > keyboard driver does. Dan's argument really says that the BIOS is does > not do the kind of interrupt I/O that a multitasking operating system > needs because if we let the BIOS keyboard driver handle the keyboard > interrupt, the process waiting for the character will never know > its there unless it checks explicitly. Therefore, the BIOS driver must > be replaced with another one that will signal the OS when a character > arrives. No, that's not what I said at all. Please don't rewrite me... The idea is to catch INT 9 and then PASS IT ON to the BIOS. Next, using this as a hint that there might be something to read from the keyboard, invoke the non-blocking read character/status call and (possibly) the destructive read call until the buffer is drained. This has many advantages. The standard BIOS calls are used. The BIOS takes care of all character encoding, shift keys, etc... Your operating system is isolated from the hardware and thus runs on many (partly incompatible) clones. Some clones that don't use INT 9 are so thoughtful as to simulate one every time a key is struck, so this still works! The net effect is completely indistinguishable from an interrupt-driven keyboard. In fact, it is an interrupt-driven keyboard. The confusion seems to stem from not differentiating between the BIOS interrupt service routine (which does just what you want; shoves characters into a buffer) and the BIOS user-level calls which don't do quite what you want but can be trivially coerced to do so. Or maybe it isn't clear how easy it is to intercept an interrupt rather than replace it. Take my word for it, it is much easier. Just not having to worry about sending the eoi to the interrupt controller improves portability considerably. Now before you tell me this won't work, note that it is not a theoretical argument; this is the way I do keyboard I/[O] in OS. Also note that I am not praising the BIOS code; I hate it just as much as the next guy. But the thought of writing n different keyboard drivers for n different clones when a much simpler approach would work was very persuasive. Dan Lanciani ddl@harvard.*
thomps@gitpyr.UUCP (02/11/87)
In article <1198@husc6.UUCP>, ddl@husc6.UUCP (Dan Lanciani) writes: > In article <3071@gitpyr.gatech.EDU>, thomps@gitpyr.gatech.EDU (Ken Thompson) writes: > > I believe Dan, Phil and Andy T. are talking about the same thing > > here. .... > No, that's not what I said at all. Please don't rewrite me... > The idea is to catch INT 9 and then PASS IT ON to the BIOS. Next, using > this as a hint that there might be something to read from the keyboard, > invoke the non-blocking read character/status call and (possibly) the > destructive read call until the buffer is drained. This has many advantages. > The standard BIOS calls are used. The BIOS takes care of all character > encoding, shift keys, etc... Your operating system is isolated from > the hardware and thus runs on many (partly incompatible) clones. Some > clones that don't use INT 9 are so thoughtful as to simulate one every > time a key is struck, so this still works! The net effect is completely > indistinguishable from an interrupt-driven keyboard. In fact, it is > an interrupt-driven keyboard. Sorry I misinterpreted what you were trying to say. I think if you will look back at what you wrote you will see that it is not 100% clear that the interrupt was to be passed on to the BIOS after you caught it. > The confusion seems to stem from not differentiating between > the BIOS interrupt service routine (which does just what you want; shoves > characters into a buffer) and the BIOS user-level calls which don't > do quite what you want but can be trivially coerced to do so. Or maybe > it isn't clear how easy it is to intercept an interrupt rather than > replace it. Take my word for it, it is much easier. Just not having > to worry about sending the eoi to the interrupt controller improves > portability considerably. > Now before you tell me this won't work, note that it is not > a theoretical argument; this is the way I do keyboard I/[O] in OS. I am not an expert on BIOS so I am perfectly willing to accept that this will work. It certainly sounds like it should. By the way, I have not had any trouble replacing the interrupt in a techical sense (which has nothing to do with whether it is worthwhile to write a new driver) so I would believe catching it and passing it on would not be difficult. It seems a pretty klugey way have doing things however. I suppose choosing whether to do it that way (assuming BIOS is otherwise sufficient to support) multitasking would depend on how important having a nice clean OS is versus how important it is to run on the maximum number of clones. Since one of the primary purposes of MINIX was to be used as a companion to Tannenbaum's book in OS courses this may have taken precedence. Maybe Andy will have a comment on this. -- Ken Thompson (No not that Ken Thompson) Georgia Tech Research Institute Georgia Insitute of Technology, Atlanta Georgia, 30332 ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!thomps
davidsen@steinmetz.UUCP (02/11/87)
In article <2529@well.UUCP> hrh@well.UUCP (Harry Henderson) writes: >My apologies if this is a dumb question, by why the design decision to >make MINIX so hardware-dependant. Why wasn't the BIOS used? Does the >BIOS not provide enough functionality? If the problem is just speed, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I a word, no. The BIOS does not overlap i/o and CPU. While you are reading or writing a disk the CPU sits and waits. Likewise console and serial i/o. A multitasking o/s needs to run jobs (or kernel) while the i/o grinds away. >why not write a slower version for those of us whose chips don't have >the right pedigree? The hardware dependance strikes at one of the >basic tentents of UNIX philosophy. The standalone shell of PC/IX seems to use the BIOS for the install process. This lets the system install on systems on which it can't execute. The reason was to keep the sash small enough to fit on one 360k floppy. -- bill davidsen sixhub \ ihnp4!seismo!rochester!steinmetz -> crdos1!davidsen chinet / ARPA: davidsen%crdos1.uucp@ge-crd.ARPA (or davidsen@ge-crd.ARPA)