Browse Prior Art Database

Microkernel Interrupt Services

IP.com Disclosure Number: IPCOM000117536D
Original Publication Date: 1996-Mar-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 4 page(s) / 159K

Publishing Venue

IBM

Related People

Srinivasan, R: AUTHOR

Abstract

Disclosed is the injection of command handlers written by IHVs into the microkernel. A preferred method enables command handlers defined by Message Interface Generator (MIG) IDL to be injected as part of an I/O extension written by IHVs. Further disclosed is the dynamic injection of I/O extensions into the kernel.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 41% of the total text.

Microkernel Interrupt Services

      Disclosed is the injection of command handlers written by IHVs
into the microkernel.  A preferred method enables command handlers
defined by Message Interface Generator (MIG) IDL to be injected as
part of an I/O extension written by IHVs.  Further disclosed is the
dynamic injection of I/O extensions into the kernel.

      Fig. 1 is a block diagram providing an overview of the
interrupt services subsystem of the microkernel.

      Fig. 2 is a block diagram showing the components of an I/O
extension on the system, which represent the software embodiment of
an I/O function provider, having well-defined building blocks, such
as one or more interrupt service routines, deferred interrupt
routines, and command handlers.  An I/O extension is characterized by
the I/O functionality it adds to the base kernel of the system.
Typically, an I/O extension, containing device-specific code, is
dynamically installed, configured, or removed using loader services
outside the base kernel.  An I/O extension is flexible and scalable
enough to be a small in-kernel interrupt handler in a low-end,
user-level device driver scenario, or a full-fledged,
high-performance file system completely prepared outside the kernel
and dynamically loaded.

      Fig. 3 is a block diagram of a multiple nested hierarchy in
which the root I/O extension is the starting point.  This hierarchy
encapsulates the functionality of the first-level interrupt
controller of the system, encompassing software abstractions relating
to individual IRQs of the system interrupt controller as sockets.
These sockets are tailored to represent different trigger types, with
their corresponding dispatch methods, facilitating dynamic
reconfiguration of such attributes.  The sockets are software
abstractions, which are perceived and implemented to suit the
specific needs of a system.  The root I/O extension is modelled as
any other I/O extension on the system, having the same entry points.
This architecture enables dynamic selection and configuration of root
I/O extensions based on residual data indicating, for example, the
controller type and individual trigger types to the operating system.

      Multiple connections to the command handler are supported,
facilitating the distribution of client communications to a single
instance of a command handler server.  Modelling power is given to
the IHVs for designing and defining their respective driver
frameworks.  Generic services are provided to the injected command
handlers for communicating with other components of I/O extensions,
such as ISRs and deferred interrupt handlers.  This method ensures
that, once an underlying IPC framework is set up by the interrupt
services for multiple client connections to an I/O extension, command
handler entry points are invoked directly, without any intervention
from the microkernel.

      Once an I/O extension has been registered with the kernel
using t...