Browse Prior Art Database

Method and System for Managing Multiple Software Hook Consumers in a High-performance Environment

IP.com Disclosure Number: IPCOM000168279D
Original Publication Date: 2008-Mar-05
Included in the Prior Art Database: 2008-Mar-05
Document File: 2 page(s) / 47K

Publishing Venue

IBM

Abstract

Managing multiple software hook consumers in a high performance environment

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 2

Method and System for Managing Multiple Software Hook Consumers in a High-performance Environment

Operating systems typically provide for a method of access to either an administrator or utility which can extend or customize the operating system behavior for specific functionality. When implementing such as system on a high-performance system such as z/TPF, the facility to manage such extension points or "hooks" can be optimized in a way that meets these criteria:
1. Performance
2. Atomicity
3. Dynamic change

    
To meet the performance characteristic a hook must be prepared to scale based on the needs of the operating system - one hook point may support multiple hook handlers - but when a hook is not active there should be negligable performance impact. For example, a common extension point may be a "C function entry" hook, which may be used for example by the "C function trace" facility, the "debugger" facility, the "performance analyzer", the "Data collection" facility, etc. If only one of these hooks is active there should be no performance overhead from the inactive hooks. Likewise, if no handlers are active the hook should cause minimal overhead.

     To meet the atomicity characteristic, a hook should be setup so that activating or deactivating a hook should result in a atomic state, that is there are no in-between stages where a hook is "half-on, half-off".

     To meet the dynamic change characteristic, a hook should be able to be activated or deactivated without requiring a system to be reset. For example, the "debugger" capability of the "C function entry" hook should not require a reload of the operating system.

     In the z/TPF operating system we have implemented the facility described above meeting the criteria desired. In the z/TPF operating system these hooks are defined in the low core operating system area described as the "prefix page" which is the initial memory area of the operating system. A means of describing the hook locations is provided using a macro interface. The macro to describe a hook location is the ADD_HOOK macro. This is as follows:

ADD_HOOK CP0CLANG,C_ENTER,RTNREG=R1,STK=R15,CPSTK=NO

     This describes a hook location at "CP0CLANG" location, with a name of C_ENTER. The following parameters describe the entran...