Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!husc6!ddl
From: ddl@husc6.UUCP
Newsgroups: comp.os.minix
Subject: Re: More on polled keyboards
Message-ID: <1236@husc6.UUCP>
Date: Sun, 15-Feb-87 18:39:54 EST
Article-I.D.: husc6.1236
Posted: Sun Feb 15 18:39:54 1987
Date-Received: Mon, 16-Feb-87 03:46:05 EST
References: <1070@botter.cs.vu.nl>
Distribution: world
Organization: Harvard University, Cambridge MA
Lines: 46

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.*