Abstract:
An event subscription and publication system for dynamically notifying user level applications of kernel level events. The kernel level events may include hardware and software events as well as system level errors that occur in the kernel. User level applications that need information on these kernel level events subscribe to the event monitoring and publication framework of the present invention and are notified of these kernel level events when they occur. Upon notification of an event, the user application also is provided with specific information classifying the nature and details of the event. The kernel event monitoring and publication system of the present invention allows user level applications to be dynamically notified of kernel level events without requiring the user level application to interrupt the normal processing states to identify these events when the events occur.

Description:
FIELD OF THE INVENTION  
         [0001]    The present claimed invention relates generally to the field of computer operating systems. More particularly, embodiments of the present claimed invention relate to a system for subscribing and publishing kernel level events to user level applications.  
         BACKGROUND ART  
         [0002]    A computer system can be generally divided into four components: the hardware, the operating system, the application programs and the users. The hardware (e.g., central processing unit (CPU), memory and input/output (I/O) devices) provides the basic computing resources. The application programs (e.g.,database systems, games business programs (database systems, etc.) define the ways in which these resources are used to solve computing problems. The operating system controls and coordinates the use of the hardware resources among the various application programs for the various users. In doing so, one goal of the operating system is to make the computer system convenient to use. A secondary goal is to use the hardware in an efficient manner.  
           [0003]    The Unix operating system is one example of an operating system that is currently used by many enterprise computer systems. Unix was designed to be a time-sharing system, with a hierarchical file system, which supported multiple processes. A process is the execution of a program and consists of a pattern of bytes that the CPU interprets as machine instructions (text), data and stack. A stack defines a set of hardware registers or a reserved amount of main memory that is used for arithmetic calculations.  
           [0004]    The Unix operating system consists of two separable parts: the “kernel” and the “system programs.” Systems programs consist of system libraries, compilers, interpreters, shells and other such programs that provide useful functions to the user. The kernel is the central controlling program that provides basic system facilities. The Unix kernel creates and manages processes, provides functions to access file-systems, and supplies communications facilities.  
           [0005]    The Unix kernel is the only part of Unix that a user cannot replace. The kernel also provides the file system, CPU scheduling, memory management and other operating-system functions by responding to “system-calls.” Conceptually, the kernel is situated between the hardware and the users. System calls are the used by the programmer to communicate with the kernel to extract computer resource information. The robustness of the Unix kernel allows system hardware and software to be dynamically configured to the operating system while applications programs are actively functional without having to shut-down the underlying computer system.  
           [0006]    Thus, when system hardware or software resource changes are implemented in a computer system having the Unix operating system, the kernel is typically configured or reconfigured to recognize the changes. These changes are then made available to user applications in the computer system. Furthermore, as system errors and faults occur in the underlying operating system, the kernel is able to identify these errors and faults and make them available to applications that these error and faults may affect. Applications typically make system calls by way of “system traps” to specific locations in the computer hardware (sometimes called an “interrupt” location or vector) to collect information on these system errors. Specific parameters are passed to the kernel on the stack and the kernel returns with a code in specific registers indicating whether the action required by the system call was successfully completed or not.  
           [0007]    [0007]FIG. 1 is a block diagram illustration of an exemplary prior art computer system  100 . The computer system  100  is connected to an external storage device  180  and to an external drive device  120  through which computer programs can be loaded into computer system  100 . The external storage device  180  and external drive  120  are connected to the computer system  100  through respective bus lines. The computer system  100  further includes main memory  130  and processor  110 . The drive  120  can be a computer program product reader such a floppy disk drive, an optical scanner, a CD-ROM device, etc.  
           [0008]    [0008]FIG. 1 additionally shows memory  130  including a kernel level memory  140 . Memory  130  can be virtual memory which is mapped onto physical memory including RAM or a hard drive, for example. During process execution, a programmer programs data structures in the memory at the kernel level memory  140 . User applications  160 A and  160 B are coupled to the computer system  100  to utilize the kernel memory  140  and other system resources in the computer system  100 . In the computer system  100  shown in FIG. 1, when kernel events occur, each of the applications  160 A and  160 B have to independently perform poll or query operations to become aware of these events. Furthermore, each application has to initiate system calls to the kernel  140  to extract information on a particular event.  
           [0009]    This typically results in the applications blocking or waiting for the kernel  140  to extract event information. Having the applications  160 A and  160 B independently issue system calls to the kernel to extract kernel event information further requires the applications to always preempt the kernel to extract event information. This can be inefficient, time consuming and costly. It may also require the applications to terminate or suspend other processes while preempting the kernel to extract kernel event information.  
         SUMMARY OF INVENTION  
         [0010]    Accordingly, to take advantage of the many legacy application programs available and the increasing number of new applications being developed, a system is needed that allows a programmer to add extensions to a kernel to publish the occurrence of kernel level events to user level applications data without disrupting the functionality of the kernel for other operations. Further, a need exists to use existing legacy programs without having to recompile the underlying kernel in the operating system each time a new event is published from the kernel. A need further exists for an improved and less costly program independent operating system, which improves efficiency, reliability and provides a means to compile programs without losing the embedded features designed in these programs. A need further exists to reliably publish kernel level events to application programs and transparently filter events for other programs that have no need for these events.  
           [0011]    What is described herein is a computer system having a kernel structure that provides a technique for monitoring and publishing kernel level events to user level applications by an asynchronous notification mechanism without having to recompile the kernel modules that publish the events. Embodiments of the present invention allow programmers to add system level loadable modules to existing kernel modules and provide a mechanism to extract and publish events to the user level applications without having user applications clogging the kernel with event query or poll requests. Embodiments of the present invention allow a system event framework in the kernel to publish the occurrences of hardware and software changes to specific user applications in a computer system. These kernel events may also include kernel errors and faults. Events detected by the kernel system event framework are asynchronously published to the user applications as they occur to avoid interruption of other operations of these applications.  
           [0012]    The system event framework further provides users with a number of semantics that allow user level applications to subscribe to specific events in the kernel. The system event framework of the present invention further allows the non-interfering additions to a single entity without the need for pre-existing code to change.  
           [0013]    Embodiments of the present invention further include kernel event publication logic that identifies kernel level events based on categories submitted by kernel subsystems and publishes these events as they occur to the specific applications. In one embodiment of the present invention, the kernel event publisher allows users to dynamically add to existing event characteristics based on unique identifiers to each event that an application wishes to subscribe.  
           [0014]    Embodiments of the present invention also include event data system queues that dynamically queue the kernel events being monitored as they occur. The system event queues enable the kernel to buffer the system event data prior to dispatching the data to user level applications. The event data comprises a class and sub-class definition of the event. The event data also includes identification information that uniquely identifies each event for a particular application.  
           [0015]    Embodiments of the present invention further include event data loadable modules that are implemented as intermediaries between the user applications subscribing to the kernel events and the kernel. The system event loadable modules receive all events published by the kernel and asynchronously distribute the events to the applications based on the class and unique identifier information. The system event loadable modules may be dynamically added to the system event framework dispatching daemon of the present invention without the need to recompile the underlying framework or event consumers or producers. The system event loadable modules also include acknowledgement logic that is triggered by each application when an event is received by the application to indicate receipt of the event. This allows the kernel to flush the system event queue of pending events after the events have been delivered. Further, system event loadable modules allow new features to be added to the base framework without recompilation of framework entities, a reboot of the operating system or restarting the system event daemon.  
           [0016]    Embodiments of the present invention further include a system event daemon that accepts delivery of the kernel events and dispatches the events to the appropriate system event loadable module. The system event daemon monitors the system event loadable modules to ensure that events queued by the kernel are delivered to the appropriate applications. The system daemon further ensures that when event delivery is completed to the applications, the kernel is notified to flush the kernel event queues.  
           [0017]    Embodiments of the present invention further include event subscription logic that allows user applications to subscribe to certain kernel events. The kernel event subscription logic is based on the event class and sub-class types. The event subscription logic establishes a connection between the system event daemon and the user application to create a connection path to deliver kernel event data to the applications. The event subscription logic also manages subscribers on behalf of the system event daemon and filters the kernel event buffers for each event subscriber in order to free kernel entries.  
           [0018]    Embodiments of the present invention further include a system event configuration file registration feature that provides event information that is used by the present invention to determine when an application or script should be launched or invoked in response to a specific event. The system event configuration file feature is implemented as a loadable module to the system event framework daemon. As such, changes to the configuration file features may be made independent of the daemon and the base system event framework.  
           [0019]    Embodiments of the present invention further include a device driver interface module that enables the addition of device drivers to enable individual user applications to independently publish a kernel level events. The device driver interface module further minimizes the number of interfaces a driver must use to log a system event.  
           [0020]    These and other objects and advantages of the present invention will no doubt become obvious to those of ordinary skill in the art after having read the following detailed description of the preferred embodiments which are illustrated in the various drawing figures.  
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0021]    The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention:  
         [0022]    [0022]FIG. 1 is a block diagram of a prior art computer system;  
         [0023]    [0023]FIG. 2 is a block diagram of a computer system in accordance with an embodiment of the present invention;  
         [0024]    [0024]FIG. 3 is a block diagram of an embodiment of the kernel event monitoring framework system of the present invention;  
         [0025]    [0025]FIG. 4 is a block diagram of one embodiment of an internal architecture of a system event daemon of one embodiment of the kernel event monitoring framework of the present invention;  
         [0026]    [0026]FIG. 5 is a block diagram of one embodiment of a system event flow of the kernel event monitoring framework of the present invention;  
         [0027]    [0027]FIG. 6 is a block diagram of another embodiment of the system event flow of the kernel event monitoring framework of the present invention;  
         [0028]    [0028]FIG. 7 is a block diagram of one embodiment a public registration interface for user applications to the kernel event monitoring framework of the present invention; and  
         [0029]    [0029]FIG. 8 is a flow diagram illustration of one embodiment of an event subscription and publication of the kernel event monitoring framework of the present invention.  
     
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0030]    Reference will now be made in detail to the preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with the preferred embodiments, it will be understood that they are not intended to limit the invention to these embodiments.  
         [0031]    On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following detailed description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be obvious to one of ordinary skill in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the present invention.  
         [0032]    The embodiments of the invention are directed to a system, an architecture, subsystem and method to monitor kernel level events and to publish the occurrence of those events to subscribing user level applications. In accordance with an aspect of the invention, a kernel level event data monitoring system provides user applications the ability to dynamically receive notification of kernel events as they occur for particular applications transparently to the underlying operating system and the other applications running in the computer system.  
         [0033]    [0033]FIG. 2 is a block diagram illustration of one embodiment of a computer system  200  of the present invention. The computer system  200  according to the present invention is connected to an external storage device  280  and to an external drive device  220  through which computer programs according to the present invention can be loaded into computer system  200 . External storage device  280  and external drive  220  are connected to the computer system  200  through respective bus lines. Computer system  200  further includes main memory  230  and processor  210 . Drive  220  can be a computer program product reader such a floppy disk drive, an optical scanner, a CD-ROM device, etc.  
         [0034]    [0034]FIG. 2 shows memory  230  including a kernel level memory  240 . Memory  230  can be virtual memory which is mapped onto physical memory including RAM or a hard drive, for example, without limitation. During process execution, a programmer programs data structures in the memory at the kernel level memory  240 . According an embodiment of the present invention, the kernel memory level includes a kernel level system event framework system (KLFS)  250 . The KLFS  250  enables a programmer to subscribe to and monitor kernel level events for particular user level applications  260  that the programmer is implementing and the KLFS  250  dynamically notifies the intended applications  260  of the occurrence of such events. The notification of the subscribed events as they occur are non-interfering to other applications that may be running on the user&#39;s computer system.  
         [0035]    The KLSF  250  comprises application interfaces for kernel level publication and applications interfaces for user level notification of events occurring in the kernel  240 . The KLFS  250  provides a standardized event buffer and payload (e.g., data) that is delivered to the subscribing user applications. The KLFS  250  further comprises libraries to extract event data from the event buffers and a daemon that dispatches the events to the user level applications.  
         [0036]    [0036]FIG. 3 is a block diagram illustration of one embodiment of the kernel level system event monitoring framework system (KLFS)  250  of the present invention. The KLFS  250  comprises standardized event data module  300 , application interface (API) library module  310 , kernel publication module  320 , system event loadable (SLM) module  330  and system daemon module  340 .  
         [0037]    The standardized event data module  300  provides event handles to particular system event objects. The system event types may include a class of related event conditions or a subclass of particular conditions with a class. The event data module also provides a set of unique event identifiers that provides high resolution timestamp and sequencing numbers to uniquely identify events as they occur in the kernel  240 .  
         [0038]    The event data module  300  further provides a set of publisher identifiers that uniquely identifies each kernel event subscriber. The publisher identifiers differentiate the same event type generated from different sources or publishers. In one embodiment of the present invention, the event data module  300  further generates a set of unique data attributes that comprise a set of name-value pairs that further describe the event conditions as they occur in the kernel  240 .  
         [0039]    The kernel event publication module  320  publishes the events as they occur in the kernel  240 . In one embodiment of the present invention, each event contains a number of buffers with a set of header information. The header information is typically filled in by the KLFM  250 , except the class and sub-class information. The event buffer also contains a publisher identifier which allows the KLFS  250  to differentiate the same event from different sources. The kernel event publisher  320  also provides the data payload containing specific data that a specific publisher requires.  
         [0040]    The kernel event publication module  320  is preferably a set of routines that serve as the building blocks to the kernel&#39;s subsystem specific modules, such as the device driver interface (DDI). The kernel event publication module  320  also allocates memory for each event handle provided along with each subscription request to the KLFS  250 . The kernel event publication module  320  further frees memory associated with each event handle, e.g., freeing of header and any attribute data.  
         [0041]    In one embodiment of the present invention, the event publication module  320  also adds new attributes (name-value pair) to any system event attribute list that is created by the KLFS  250  by creating the list if the data will be the first attribute element on the list. The event publication module  320  also attaches attribute data to a previously allocated event object and similarly detaches attribute data from event objects.  
         [0042]    Still referring to FIG. 3, the system event loadable module (SLM)  330  acts as an intermediary between the user applications programs  260  making event subscriptions and the kernel  240 . The SLM  330  receives all events as they occur in the kernel  240  and passes the events on to the requesting applications  260 . In one embodiment of the present invention, the kernel level events are buffered and queued for presentation to the SLM  330 .  
         [0043]    The SLM  330  further provides a mechanism to allow the programmer (user) to add special features to the system event daemon on the user&#39;s computer. The SLM  330  primarily acts based on the event type being monitored in the kernel and subscribed by the applications program. Event buffers generated by the kernel  240  are filtered and passed by the SLM  300  to other applications in the computer system  200  as needed.  
         [0044]    The SLM  330  also provides the KLFS  250  a level of reliability to deliver kernel events to the subscribing applications. In one embodiment of the present invention, the SLM  330  communicates with the overlying applications  260  in a one-to-one relationship to ensure that events generated for a particular application are not mistakenly delivered to another application. The SLM  330  includes acknowledgement logic that acknowledges receipt of buffered event designated to the SLM  330 . The acknowledgement logic enables the KLFS  250  to release buffered events or retry delivery.  
         [0045]    The system daemon module  340  typically resides on the user&#39;s computer system and communicates to the KLFS  250  via an interface. The system daemon module  340  primarily communicates with the kernel  240  with the SLM  330  acting as clients of the system daemon  340 . The system daemon module  340  accepts delivery of system event objects from the kernel  240  and through a dispatching thread temporarily places the buffered events data on each SLM  330  client queue.  
         [0046]    Once an event delivery is made to the SLM  330 , the buffer is removed based on the acknowledgement receipt sent by the SLM  330  to the system event daemon  340 . There are several reasons for the SLM  330  to acknowledge receipt of an event delivery. One is to ensure that the event data buffers are not freed from the kernel  240  until the SLM  330  confirms it has received the event. Another is to allow the SLM  330  to request that delivery be retried if it is not able to process the event data immediately. In one embodiment of the present invention, the system event daemon dispatches the event data in a multi-threaded process to each respective SLM  330 .  
         [0047]    Reference is now made to FIG. 4 which is a block diagram illustration of one embodiment of the system event daemon  340  of the present invention. As depicted in FIG. 4, the system event daemon  340  comprises signal handling thread module  400 , dispatch buffers  410 , kernel door server thread  420 , dispatch thread  430 , delivery thread  440  and event completion thread  450 .  
         [0048]    The signal handling thread  400  receives signal handles from the applications  260  and coordinates draining of the SLM  330  queue as the data in the queues of the dispatch buffers  410  are delivered to the SLM  330 . Upon delivery of the queued buffered data, the signal handling thread  400  sends a completion signal to the kernel  240  to indicate completion of all event data delivery. This causes all outstanding event data deliveries to be flushed from the system event daemon  340 . The signal handling thread  400  then revokes the kernel door  420 . The signal thread  400  also waits for signals, e.g., HUP, INT, STOP and TERM to gracefully shut down the system event daemon. In one embodiment of the present invention, if the HUP signal is presented to the signal thread  400 , the SLMs  330  are unloaded and then reloaded.  
         [0049]    The kernel door server thread  420  handles door up-calls from the kernel and copies event objects into a waiting buffer in the dispatch buffers  410 . If the buffer  410  is unavailable, the kernel door server thread  420  returns a “not-available” signal. The kernel doors  420  typically are a mechanism by which the kernel  240  communicates with user level processes such as the system event daemon  340 .  
         [0050]    The dispatch thread  430  provides a mechanism through which the event buffers  410  are dispatched to each client (e.g., SLMs  330 ). These dispatches are accomplished by placing the buffers on a per-client event queue. Once an event buffer has been dispatched to all clients, a completion package is placed on the completion queue  450 . The completion package contains the event identifier and the client reference count.  
         [0051]    The event delivery thread  440  delivers the event data to each client subscribing to the event. Each client delivery thread extracts the next event buffer on its queue and calls the appropriate SLM  330  delivery routine to implement delivery of the event data. After a successful return from the SLM  330 , the buffer is removed from the buffer queue  410  and an event completion is signaled to the event completion thread  450  for the particular client.  
         [0052]    Once all clients have signaled completion of processing a particular event buffer  410 , the event is released from the kernel by the event completion thread  450 .  
         [0053]    [0053]FIG. 5 is a data flow diagram of one embodiment  500  of the flow of data in the kernel system event framework  250  of the present invention. As shown in FIG. 5, events generated by the kernel  240  are published by the event publisher  320  to the subscribing applications  530 . Each event is stored in an event buffer with associated payload (data). The event buffer is first allocated and initialized with event specific data provided by the kernel event publisher  320  and system specific identification (e.g., timestamp and sequencer). The event buffer is subsequently queued in the system event queue  520  for delivery to the system daemon  340 . Each event buffer includes a set of header information. The header information is typically filled in by the system event framework  250 , except the class and sub-class information.  
         [0054]    Each system event buffer includes an event type, which comprises a class and a sub-class. An event class typically defines a set of related event conditions and the sub-class defines a particular condition within the class. The event buffers also include a unique event identifier that is unique to each event buffer in the system queue  520 . In one embodiment of the present invention, the event identifier comprises a high resolution time stamp and a sequence number for each event. An exemplary event may be defined as follows:  
         [0055]    event header  
         [0056]    class  
         [0057]    subclass  
         [0058]    timestamp  
         [0059]    sequencer  
         [0060]    vendor  
         [0061]    publisher  
         [0062]    self-describing event* class-specific data (e.g., name-value pairs).  
         [0063]    where:  
         [0064]    class is the class of the event;  
         [0065]    sub-class is the sub-class of the event;  
         [0066]    vendor is the name of the vendor defining the event, for example the stock symbol of the vendor;  
         [0067]    publisher is the name of the application, driver or system module producing the event;  
         [0068]    timestamp is a high resolution time assigned at event buffer initialization time;  
         [0069]    sequencer is a monotonically increasing value assigned at initialization time.  
         [0070]    Events from the system event queue  520  are extracted by the system daemon  340 . The daemon  340  retrieves from the system event queue  520  the event buffers and through a dispatching thread places the buffers in each respective client&#39;s (applications  530 ) queue for delivery. Each of the applications  530  has an event buffer queue that stores events generated by the kernel  240 .  
         [0071]    Once delivery is made to each of the modules  1 - 3 , the buffer is removed from the daemon&#39;s event completion thread. In one embodiment of the present invention, the event buffers are not removed from the daemon&#39;s event completion thread until each of modules  1 - 3  confirms receipt of the event. Confirmation of the receipt of events ensures the reliable delivery of events to the SLMs  330 .  
         [0072]    [0072]FIG. 6 is a data flow diagram of another embodiment  600  of event data flow in the present invention. In the embodiment disclosed in FIG. 6, a configuration file  610 , a configuration file daemon  620  and a sys event post file  630  are added to the kernel system event framework  250 . Based on the contents of the configuration file  610 , an application is launched or invoked in response to a particular event.  
         [0073]    The configuration file  610  provides class, sub-class, publisher and arbitrary attribute data that is used to indicate when an application should be launched. For example, if a user wishes to subscribe to event information for when a printer is either configured or de-configured to the system, the configuration file  610  is configured with the printer name, etc. The printer detect logic in the kernel  240  is invoked to configure the printer information in the kernel sub-systems and generate an event ( e.g., addition of a new printer) to all applications subscribing to be notified of the addition or deletion of printers from the kernel  240 .  
         [0074]    An exemplary configuration file of one embodiment of the present invention is as follows:  
                                                                         “class; sub-class; vendor; publisher; reserved1; reserved2; path[arg1            arg2 . . . ]”       For example: with an event described by:            class event vendor pub user flag service   [arg1 arg2 . . . ]            ec_conf esc_dc QQQ qd - - /opt/QQQ/qd/bin/qdconfig -c       ${device_name}                  
 
         [0075]    where:  
         [0076]    class is the class of the event;  
         [0077]    sub-class is the sub-class of the event;  
         [0078]    vendor is the name of the vendor defining the event, for example the stock symbol of the vendor;  
         [0079]    publisher is the name of the application, driver or system module producing the event;  
         [0080]    timestamp is a high resolution time assigned at event buffer initialization time;  
         [0081]    sequencer is a monotonically increasing value assigned at initialization time.  
         [0082]    The sys event post API  630  allows user level applications to generate events similar to events generated by the kernel  240 . In the embodiment shown in FIG. 6, the system event framework  250  further includes a device driver system event interface  605 . A wrapper function logic in the system event post event file  630  enables the addition of a device driver interface (DDI) that allows device drivers to call the SLMs  330  to place events. The DDI interface calls specific driver interface conventions and returns DDI specific errors in case of a failure. In one embodiment of the present invention, the DDI interface minimizes the number of interfaces a driver must use to publish system events.  
         [0083]    [0083]FIG. 7 is a block diagram illustration of one embodiment of system event subscription logic  700  of the present invention. The system event subscription logic  700  provides a mechanism for the system event framework to establish connections between the system event daemon and a subscribing application. A handle is created to hold the connection path and the subscribing application. The system event subscription logic  700  further provides the kernel system event framework  250  with a mechanism to free previously allocated system event handles generated by the system event daemon  340  after events have been delivered to the subscribing applications. The system event subscription logic  700  further includes a system event unsubscribe logic that allows the system event framework  250  to disable delivery of system event notifications to subsequent system events that occur in the kernel according to a system event type list. In one embodiment of the present invention, the system event type list may be used to subscribe to events of interest to the subscribing application.  
         [0084]    The event subscription feature is implemented as a special purpose SLM  330 . User applications may engage in event subscription in the present invention through library interface  310  that establishes and maintains event subscription connection paths between the event subscription SLM and the subscribing application. The system event daemon  340  opens the libraries and delivers event buffers to the SLMs  330  and the SLM  330  in turn delivers the event buffers to the user application. The event buffers are asynchronously delivered to the user application via, for example, call back routines in which system programs deliver the event buffers to the user applications.  
         [0085]    In the example shown in FIG. 7, events from the system event daemon  340  are passed to the event dispatcher  711  and queued for delivery in the system event queue module  712 . The queued events are then provided to the event delivery module  713  which delivers the events to the event subscriber SLM. The event subscriber SLM in-turn makes door calls to the door server  718 ,  725  and  735  for each respective subscriber application  720 ,  730  and  740  to make delivery of each respective system event buffer (A-C) to each respective application. Each of the event handles  719 ,  727  and  738  establishes a connection between the system event daemon  340  and the subscribing application. The handle holds the connection path (e.g., file system name) and the calling applications&#39; event delivery routine. After an event is delivered, the handles respectively close the connection between the system event daemon and the calling application and frees the system event daemon handles previously allocated.  
         [0086]    [0086]FIG. 8 is an exemplary computer controlled flow diagram of one embodiment of event subscription and delivery of the present invention. As shown in FIG. 8, implementation of an event subscription and delivery is initiated by a computer system user application subscribing to the kernel system framework  250  event notification logic for particular events. At step  810 , the kernel system framework  250  allocates and initializes event buffers for the events being subscribed. At step  820 , the framework  250  queues the event buffers for delivery. After the event buffers have been queued, the framework  250  notifies the system event daemon  340  of the queued events.  
         [0087]    At step  825 , the queued event buffers are extracted and dispatched at step  830  to the corresponding SLMs  330 . At step  835 , the event subscription SLM  330  checks for subscribing users or applications to the queued events. At step  840 , the subscribing SLM  330  determines whether the identified subscribers have subscribed to a particular event type.  
         [0088]    If the identified subscribers have subscribed to the specific event type determined by the subscribing SLM  330 , the framework  250  opens connection to the particular application for event delivery at step  845 .  
         [0089]    At step  850 , the framework  250  checks to determine whether a queued event buffer has been successfully delivered to the subscribing application. If the event has been successfully delivered, the framework  250  returns success at step  855  to the dispatching SLM  330  and continues delivery of other events in the queue buffer. If an event is unsuccessfully delivered, a return retry is signaled to the dispatching SLM  300  at step  860 .  
         [0090]    At step  865 , the framework  250  performs a second check to determine whether an event buffer has been delivered. If during this check the event buffer has been delivered, the event buffer is freed at step  870  and processing ends at step  880 . If, on the other hand, the event buffer has not been delivered, the framework  250  performs a delivery retry at step  875 , to re-deliver the event buffer.  
         [0091]    In a typical operation of one embodiment of the KLFS  250 , the event publisher  310  calls the system event allocation and initialization module  510 . The system event allocation and initialization module  510  has the event data which includes the class, sub-class, publisher identifier and attribute data. The KLFS  250  then places the event data into a single buffer for each event. The system daemon  340  in communicating with the kernel  240  extracts the event buffers stored in the system event log  320  and dispatches the event data to the SLMs  330  which subsequently place the event buffers in each subscribing applications individual event buffers. For example, if there is a fault condition in the kernel  240  as a result of a device driver receiving many time-outs at its ports. The kernel  240  will call the system event log  320  to log the particular condition. The KLFS  250  will then compose the fault event class as, for example, “an ec_fault”; a sub-class will be defined as “time-outs” and the KLFS  250  will fill the unique identifier for the event and the event publisher will further publish the event in terms of the attribute data.  
         [0092]    In this example, the attribute data will be defined as a set of name-pair value (e.g., time-out with an intrinsic value specifying the time-out limit). Applications subscribing to this event will extract the event data and notice the time-out limit (e.g.,  3 ) and will be able to dynamically adjust processing to the specific device driver when the time-out is over.  
         [0093]    The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the claims appended hereto and their equivalents.