Section
3.2
Driver documentation
This section discusses how the "binddrivers" program finds your
driver and links
it
into the system.
It
also hints on how to write your
code to take advantage of this.
First off, the expansion library goes out and configures the expan-
sion boards in the system.
It
puts each board in
its
own address
space, and links memory boards into the memory free pool. This is
done by the
expansion.librarySs Configchain entry point. This code
is
intended to be run early on in system startup, before any other code
is around.
Later on, after the DOS is running, the binddrivers program should
be run. This program searches the directory
"SYS:Expansion" for
workbench icon files. If
it
finds one with a tooltypes variable "PROD-
UCT" then
it
parses the rest of the line (see below) and looks for an
unconfigured board that matches the description.
This method makes user installation of a new driver trivial: the user
only has to copy a workbench icon into the expansion directory on
his
sys disk. Everything else
is
automatic the next time he boots.
In addition, the bootdrivers program may be run repeatedly without
ill
effect. Devices will not be configured twice, so binddrivers may be
run after a new driver is installed (so the user does not have to re-
boot after installing a driver).
OVERVIEW
Here
is
an overview of the process:
search:
for each file that ends in .info, do test
(
).
test:
1.
Call GetDiskObject(
)
on this file. If not a workbench object, re-
turn.
2.
Call FindToolType
( )
to see if there is a PRODUCT definition. If
not, return.
3.
If the description does not match an unconfigured board, return.
If there are boards, link them all together and
rkcord them in a
static area.
4.
LoadSeg
( )
the code file. If LoadSeg fails, return.
5.
Search the first hunk for a Resident structure. If no structure.
UnLoadSeg
(
)
the segment and return.
To Next Page
Loading...
