Making the transition to a full driver
Once the kernel is running and interrupts are enabled, the minidriver continues to be called when the interrupt that it's attached to is triggered. This action can continue for the lifetime of the system; in other words, the minidriver can behave like a tiny interrupt handler that's always active.
Usually the hardware needs more attention than the minidriver is set up to give it, so you'll want the minidriver to hand off to a full driver.
Here's the sequence of events for doing this:
- The full driver locates the minidriver's entry in the system page by using the SYSPAGE_ENTRY() macro. For an example, see the entry for mdriver_entry in this guide.
- The full driver maps the minidriver's data area into its memory space.
For example:
dptr = mmap( 0, 65536, PROT_READ | PROT_WRITE | PROT_NOCACHE, MAP_PHYS | MAP_SHARED, NOFD, SYSPAGE_ENTRY(mdriver)->data_paddr ); - The full driver can do post-processing of existing data.
Since the minidriver is still running at this point, it continues to run whenever the interrupt is triggered. Depending on the design, it may be necessary to do some processing of the existing data that has been stored by the minidriver before the full driver takes control.
- The full driver attaches to the interrupt by calling
InterruptAttach()
or
InterruptAttachEvent().
For safety, the full driver should always disable the device interrupt before calling InterruptAttach() or InterruptAttachEvent(), and then enable the interrupt upon success.
- When the full driver attaches to the interrupt, the kernel calls the minidriver with a state of
MDRIVER_INTR_ATTACH.
The minidriver should do any cleanup necessary, disable the device interrupt, and then
return a value of 1 to request that the kernel remove it.
After this, the minidriver is no longer called, and only the full driver receives the interrupt.
- The full driver begins to handle the device and process any device data that was stored in the minidriver data area.