Intro --
introduction to SCO OpenServer DDI driver entry-point routines
Description
Section D2oddi describes the system entry-point routines
that are supported on SCO OpenServer systems.
Entry-point routines are called by the operating system
through switch tables such as bdevsw and cdevsw
or the interrupt dispatch table or some similar table.
The names of entry-point routines must follow
a strict formula: the name of the entry-point routine
as documented in this section,
preceeded by the driver's prefix
as registered in the driver's
mdevice(F)
table.
For example, the
open(D2oddi)
routine that is called in response to an
open
system call would be named
myopen( )
if my were the driver's prefix.
Each entry point is defined as operating in a
context.
This determines which kernel functions can be called
from that routine.
The
Section D3oddi manual pages in Section D3oddi manual pages
each identify the contexts in which
that function can be called.
SCO OpenServer entry point routines (non-STREAMS, non-SCSI drivers)
Routine
Context
Block
Character
Notes
close
blockable
o
o
exec
user
o
o
exit
user
o
o
halt
blockable
o
o
init
initialization
o
o
intr
interrupt
rh
rh
ioctl
user
--
o
kenter
interrupt
o
o
kexit
interrupt
o
o
open
blockable
r
r
poll
interrupt
--
o
print
interrupt
r
--
pminit
initialization
o
o
probe
initialization
r
--
proc
user
--
o
read
user
--
o
start
non-blockable
o
o
strategy
blockable
r
o
swtch
interrupt
o
o
write
user
--
o
KEY
o
optional
r
recommended
h
used mostly for hardware drivers
--
not supported
SVR5 DDI compatibility
Section D2oddi manual pages in Section D2oddi manual pages
documents the DDI entry point routines
that correspond to those in this section.
For DDI versions prior to version 8,
most of the entry point routines are similar
to those supported for ODDI,
although there are syntactical differences:
Most DDI entry point routines
return an int that indicates
whether or not the routine executed successfully.
Most ODDI entry point routines
are cast as void and do not return a value,
but rather call
seterror(D3oddi)
or set u.u_error directly to indicate an error.
Most DDI entry point routines
take a cred_t argument
in addition to the arguments used for ODDI.
DDI 8 and later versions
use a slightly different set of entry point routines
and introduce additional semantic differences:
The dev_t argument is replaced by
arguments for the device instance and channel number.
See
``Device instance'' in HDK Technical Reference
and
``Channel number'' in HDK Technical Reference.
Entry points are declared in the
drvops(D4)
structure rather than using the named-entry point scheme
and being accessed through switch tables.
See
``Porting drivers to DDI 8'' in Developing DDI kernel drivers
for more information about differences between
ODDI and DDI entry point routines.
External dependencies
Each manual page in this section
provides detailed information about
how the entry point routine is identified to the system.
In most cases, the entry points are identified
by a letter in the
mdevice(F)
file.
file.