Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!mit-eddie!genrad!decvax!tektronix!reed!percival!nerd
From: nerd@percival.UUCP
Newsgroups: comp.os.minix
Subject: use of bios routines in the minix kernal, why not?
Message-ID: <431@percival.UUCP>
Date: Tue, 10-Feb-87 10:48:57 EST
Article-I.D.: percival.431
Posted: Tue Feb 10 10:48:57 1987
Date-Received: Fri, 13-Feb-87 06:26:58 EST
References: <172@axis.UUCP> <1192@husc6.UUCP>
Reply-To: nerd@percival.UUCP (Michael Galassi)
Distribution: world
Organization: Percy's UNIX, Portland, OR.
Lines: 62
Keywords: interupt poll
Summary: it takes more than interupts to do multi-tasking

philip@axis.UUCP
>> 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.

ddl@husc6.UUCP
>	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.

Nope, sorry, the combination gives you a polled keyboard.  As things stand
now, if you call the bios to do a read it will sit there and *poll* the FIFO
status until it finds that a key has been hit, then it returns with the
key's value.  Alternately your code could check the FIFO status and loop until
something showed up (duplicating the bios' code), you would still be polling
the keyboard's queue.  While it may be different in words the result is stil
that the cpu is doing nothing usefull while waiting for the slowest link in
the computing machine (the live-ware).
For a device to be usefull in a multi-tasking environment it's driver must
take requests for an action (input/output/status check/whatever) and release
the cpu to work on other things until the device is ready, then wait for the
cpu to come back.
What it all comes down to is that it is not suficient for a periferal driver
to be interupt driven, the driver also has to be designed to be respectfull
of resources that are not its own to alocate (i.e. cpu time).
There are several other requierments like reentrancy but that is another
subject which I will touch upon some other time when I don't have to go off
to work.

ddl@husc6.UUCP
>	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?

power the machine up, it is inherently in an unstable (unusable) state,
that is designed in to ms/pc-dos

philip@axis.UUCP
>> 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.

bravo!!!  someone has seen the light.

ddl@husc6.UUCP
>	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.			     ^^^^^^^^
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

two people have seen the light, we're on a roll now.
-- 
If my employer knew my opinions he would probably look for another engineer.

	Michael Galassi, Frye Electronics, Tigard, OR
	..!{ucbvax,ihnp4,seismo}!tektronix!reed!percival!nerd