miniFSD/OS2KRNL interface
When called from OS2KRNL after being linked into the IFS chain, the
interface will be as described in previous chapters of this document. Note
that the FS_ INIT interface for a mini-FSD has an additional parameter, as
compared to the FS_ INIT interface for an FSD.
When called from OS2KRNL, before being linked into the IFS chain, the
interface will be through the MFS_xxxx and MFSH_xxxx entry points. These
interfaces are described in this chapter. Many of these interfaces
parallel the interfaces defined for FSDs, while others are unique to the
mini-FSD.
The mini-FSD is built as a dynamic link library. Supplied functions are
exported by making the function names public. Helper functions are
imported by declaring the helper names external:far. It is required only
to support reading files and will be called only in protect mode. The
mini-FSD may NOT make dynamic link system calls at initialization time.
Due to the special state of the system as it boots, the programming model
for the mini-FSD during the state 1 time frame is somewhat different than
the model for stage 2. This difference necessitates 2 different interfaces
between OS/2 and the mini-FSD.
During stage 1, all calls to the mini-FSD are to the MFS_xxxx functions.
Only the MFSH_xxxx helper functions are available. These are the
interfaces which are addressed in this document. Many of these interfaces
parallel the interfaces defined for FSDs while others are unique to the
mini-FSD.
During stage 2, the mini-FSD is treated as a normal FSD. Calls are made to
the FS_xxxx functions and all FSH_xxxx helper functions are available.
During stage 3, the mini-FSD is given a chance to release resources
(through a call to MFS_TERM) before being terminated.
Transition from stage 1 to stage 2 is marked by calling the FS_INIT
function in the mini-FSD. Transition from stage 2 to stage 3 is marked by
calling FS_ INIT in the FSD.
Figure 4-3 on page 4-6 shows the functions called during a typical boot
sequence:
-------------------------------------------------------------> time
stage1 stage2 stage3
MFS_INIT
MFS_OPEN
MFS_READ
MFS_CHGFILEPTR
MFS_CLOSE
FS_INIT
FS_MOUNT/ATTACH
FS_OPEN
FS_READ
FS_CHGFILEPTR
MFS_TERM
Figure 4-3. Typical boot sequence
No files are open at the transition from stage 1 to stage 2. Also, only a
single file at a time is open during stage 1. Files and volumes are open
during the transition from stage 2 to stage 3 (the mini-FSD to the FSD).
The FSD must do whatever is necessary for it to inherit them. The FSD will
not receive mounts/attaches or opens for volumes and files which were
mounted/attached and opened by the mini-FSD. Also, multiple files may be
open simultaneously during stages 2 and 3.
A special set of helper functions are available to the mini-FSD to support
an imbedded device driver. This might be required for situations such as
remote IPL where the boot volume is not readable through DOVOLIO. These
special helper functions (referred to as imbedded device driver helpers)
are available during all stages of the mini-FSD's life. Note that the list
of error return codes for the helper functions is not exhaustive, but
rather represents the most common errors returned.
Because the mini-FSD is a new component added to the boot sequence, a new
interface to OS2LDR is required.
The name and attributes of the mini-FSD must match EXACTLY the name and
attributes of the replacement FSD.
Due to the instability of the system during initialization, any non-zero
return code indicates an error has been encountered. The actual return
code may not bake any sense in the context of the function called (for
example, having ERROR _ACCESS_DENIED returned from a call to MFSH_LOCK
when in fact an invalid selector was passed to the helper). It is also
possible for the system to hang or reboot itself as a result of invalid
parameters being passed to a helper function.
Created using Inf-PHP v.2 (c) 2003 Yuri Prokushev
Created using Inf-HTML v.0.9b (c) 1995 Peter Childs