Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!unirot!ron
From: ron@unirot.UUCP
Newsgroups: comp.os.minix
Subject: Re: Which clones *don't* run MINIX
Message-ID: <333@unirot.UUCP>
Date: Sun, 8-Feb-87 15:19:30 EST
Article-I.D.: unirot.333
Posted: Sun Feb  8 15:19:30 1987
Date-Received: Mon, 9-Feb-87 04:09:35 EST
References: <275@ihnp3.UUCP> <459@moncol.UUCP> <2529@well.UUCP> <447@uokmax.UUCP>
Organization: Public Access Unix, Piscataway, NJ
Lines: 16
Keywords: MINIX BIOS COMPATIBILITY

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