Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!apple!portal!cup.portal.com!ts
From: ts@cup.portal.com (Tim W Smith)
Newsgroups: comp.unix.sysv386
Subject: Why don't they use INT 13h throughout boot?
Message-ID: <35811@cup.portal.com>
Date: 10 Nov 90 16:00:02 GMT
Organization: The Portal System (TM)
Lines: 50

I've seen three different methods used to boot non-DOS operating
systems on 386 machines.  One (used by Netware 386) is for DOS to
boot, and then a DOS application is run which loads the OS.  The
OS is stored as a DOS file on a DOS partition on the hard disk.

The second, which was used by 386/ix 1.0.6 (the last version of
386/ix that I used) is for the boot program that is loaded from
the Unix fdisk partition to read in the OS from the Unix filesystem.
This boot program uses the INT 13h BIOS function to perform the
disk I/O.  INT 13h is used up until the OS is loaded, at which
point the Unix disk driver is used for any subsequent disk access.
This is also the method used by Netware 286.

The third, which is used by SCO Unix 3.2, is for the boot program
that is loaded from the Unix fdisk partition to load the OS, or
load other boot programs from the Unix partition that load the OS
(I'm not quite sure which boot program does what here).  At some
point before the OS is loaded, the boot programs start manipulating
the disk hardware directly.  I suspect that they also switch the
processor to protected mode before loading the OS.

Why is this third method used?  It seems to me that the first or
second methods are vastly superior.  Consider, for example, trying
to add support for a new disk controller.  The vendor of the disk
controller starts out by producing a Unix disk driver that knows
about their controller, and they link this into the kernel.  Assume
that the disk controller is also meant to work with DOS, so it
contains a BIOS ROM that installs an INT 13h handler at power up
time before the boot sequence begins.

If the first or second boot schemes mentioned above are used, then
the controller vendor does not have to do anything else to allow
Unix to boot off their controller.

Compare this to the third method.  Unless the controller vendor
can convince the OS vendor to modify the boot code to recognize
the new controller, the new controller can only be used to support
secondary disks, or the system must be booted from a floppy and
convinced that rootdev, swapdev, etc., are on the new disk (not
a problem, at least, with SCO, since their boot program takes
these as arguments).

So, why do people use the third method?  Do any of the Unix vendors
use the first or second in current releases?  Is it really as big
of a problem as I think, or am I just prejudiced because I write
SCSI software, and have to keep explaining to my boss that it's
not my fault that Unix can't boot ("The guys doing DOS, OS/2,
Netware 286, and Netware 386 are all booting!  Why can't you?") :-)

					Tim Smith