ast@botter.UUCP (02/13/87)
Re the discussion on polled keyboards- I think that using INT 9 like that is a dreadful kludge, furthermore it doesn't buy you anything. Those clones that are incompatible are incompatible not due to their keyboards, but due to their disks and other devices. So to use the BIOS in a multiprogramming system you would have to find some equally awful kludge to get control away from the BIOS after it started the disk up, and then catch the disk interrupt yourself and jump back into the middle of the BIOS to get it going again. Furthermore, you would have to make sure no other processes made BIOS calls while waiting for the disk I/O to complete (which can take a looong time on a floppy whose motor is initially off). I just don't think a set of weird kludges, one per device type is a nice way to program a multiprogramming system. These things are complicated enough even when programmed in a straightforward way. Another facet of the BIOS issue is that the BIOS performance is not always stellar. While this was not top priority in MINIX, a lot of commercial software bypasses the BIOS (especially the screen BIOS) for this reason. Andy Tanenbaum
ddl@husc6.UUCP (02/16/87)
In article <1070@botter.cs.vu.nl>, ast@botter.cs.vu.nl (Andy Tanenbaum) writes: > Re the discussion on polled keyboards- I think that using INT 9 like that is > a dreadful kludge, furthermore it doesn't buy you anything. Those clones > that are incompatible are incompatible not due to their keyboards, but due to > their disks and other devices. Not true--many clones use the same floppy devices but insist on having different keyboard scan codes. > So to use the BIOS in a multiprogramming > system you would have to find some equally awful kludge to get control away > from the BIOS after it started the disk up, and then catch the disk interrupt > yourself and jump back into the middle of the BIOS to get it going again. Or else you can just make the operation preemptable. > Furthermore, you would have to make sure no other processes made BIOS calls > while waiting for the disk I/O to complete (which can take a looong time on > a floppy whose motor is initially off). I just don't think a set of weird > kludges, one per device type is a nice way to program a multiprogramming > system. These things are complicated enough even when programmed in a > straightforward way. Just like you have to make sure no other request gets to the hardware while you are waiting for I/O to complete (which can take the same long time on a floppy whose motor is off). This is what queued I/O is all about and has nothing to do with using or not using the BIOS. Try to think about the BIOS as an extension of the hardware in this case; it requires mutual exclusion. In OS I have a set of generic disk I/O queue routines. They take transactions and sort them into a queue, making the obvious optimizations. These routines can be used by either of two types of devices. Smart devices pull transactions off the queue and start I/O which is reported complete at interrupt-time. Dumb devices e.g., byte-at-time floppy controllers, pull transactions off the queue and then work on them in a process context, giving up the cpu as necessary to wait for events. While one I/O operation is in progress, other operations are placed in the queue. The bottom line is that it is fine to criticize use of the BIOS for philosophical reasons, but it highly misleading to claim that it is not possible to use the BIOS in a multi-tasking environment or even that it is unduly inefficient to do so. Dan Lanciani ddl@harvard.*
ast@botter.UUCP (02/17/87)
I would be curious to know what kind of kludge is needed to make the following work in the normal way. When the operating system wants to read a disk block, it calls the BIOS. The BIOS then issues a disk command. The question is how does the operating system arrange for the BIOS to release control so that the OS can switch to another process while the operation is being carried out? This is the essence of multiprogramming, after all. In the IBM Technical Reference Manual BIOS listing, after the BIOS has issued a hardware command, it goes to line 2916 where it sits in a tight little loop (lines 2916 to 2927) until the interrupt happens. It does not give control back to the operating system so that another process can be run while waiting for the interrupt. Andy Tanenbaum
zemon@felix.UUCP (02/20/87)
In article <1071@botter.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >I would be curious to know what kind of kludge is needed to make the >following work in the normal way. Replace the BIOS. I believe this was done recently by Arnie Tan N. Balm "over there" in Europe somewheres. You might write to the Apprentice's Hall and ask for a copies of the mini-icks book and sources on paper tape. -- Art Z. P. S. The preceding message has been brought to you by my conscience. It's telling me that it's time to go home. So I guess I will -- but not before I hit the <SEND> key. Cheers! -- -- Art Zemon FileNet Corporation Costa Mesa, California ...!hplabs!felix!zemon
comp13@tjalk.UUCP (02/20/87)
In short, if you talk about a PC or XT I don't think it is possible. The BIOS of these machines have no hooks and since the BIOS is in ROM even if you would know where to patch an 'iret' or so, you couldn't patch it anyway (because it is in ROM. As you know, the AT has hooks using INT 15h with a sub-code. Let's join the original design: forget the BIOS! Paul Ogilvie