Generalised program hooks

Details Generalised program hooks Generalised program hooks

2001-07-05

2004-07-27

Chaudhuridas, Chameli (Department: 2122)

Data processing: software development, installation, and managem

Software program development tool

Testing or debugging

C717S131000, C717S127000, C717S128000, C714S034000, C714S035000, C714S047300, C712S227000, C709S230000

Reexamination Certificate

active

06769117

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to an interface module and method for allowing other modules to gain control at specified points in the execution of a program for the purpose of providing modified functionality to that of the program. The invention is particularly applicable to enhancements that provide some form of system instrumentation such as monitoring and measuring capability for performance and diagnostic purposes.
2. Description of the Related Art
In the case of, for example, the Linux operating system, the normal mechanism for making modifications to the kernel is to modify the kernel source code directly and recompile the kernel. Since the kernel source is distributed to the user, modifications are usually applied by the user, by means of an automated script containing embedded source code, known as a patch. The user recompiles the kernel together with any kernel version-dependent modules to install the patch.
This has a number of disadvantages:
1. Whenever a new version of the kernel is released, which may be merely a maintenance release, the modification nevertheless has to be reapplied to the kernel.
2. The patch for applying the modification may have to be reworked for the new kernel version.
3. The modification code itself may have to be reworked to fit in with any new kernel code that directly affects the modification, which may be due in part to a stylistic organisational change in the kernel source and not necessarily a significant change in the kernel function.
4. If the modification itself needs to be changed, then this forces a rework of the patch and a subsequent recompilation of the kernel and any kernel-dependent modules.
5. If the user wishes to apply additional patches to the kernel then it is the user's responsibility to rework the patches so that they will coexist.
6. Compilation and installation of the kernel and associated modules is a lengthy task that requires the system to be restarted to become active.
Most modifications, for example, tracing, logging, debugging or other instrumentation tools, however, are usually made to insert additional or enhanced function rather than replace kernel function.
One technique used relatively broadly to allow for the addition of functionality to a general purpose program is the inclusion of exits in the source code of the program. Although, implementable in many different ways, one way to implement exits entails the user who provides modification code, knowing the location or label of an exit, having the modification code, when loaded, overwriting an exit location in the program with an entry point location in the modification code, enabling the modification code to take over program control at the exit, carry out some processing and return at the instruction following the exit. Here, the underlying function and structure of the program remains intact and so long as the exits continue to be provided from one program release to the next, users remain unaffected and neither do they need to have access to the program source code.
This technique, however, is usually employed by users (including enterprise users) of an object code only (OCO) commercial off-the-shelf (COTS) program, where the modifications to the code are specific to the user and controlled by the user.
In the case of programs such as the Linux operating system, however, development of operating system tools takes place within a diverse community of developers who in turn submit their tools for distribution with the operating system to end users.
It is therefore not possible or desirable to require each tool developer to take into account the needs of other developers when developing new tools. Without this knowledge, it is possible that more than one tool may end up vying to access an exit. The tool gaining access to the exit, that is the tool writing its entry point location into the exit location, may be determined by the order in which tools are instantiated and so may lead to non-deterministic or unpredictable operation or even failure of the operating system.
SUMMARY OF THE INVENTION
Accordingly, the present invention provides an interface module according to claim
1
.


REFERENCES:
patent: 4821178 (1989-04-01), Levin et al.
patent: 5710724 (1998-01-01), Burrows
patent: 6026235 (2000-02-01), Shaughnessy
patent: 6219782 (2001-04-01), Khan et al.
patent: 6340977 (2002-01-01), Lui et al.
patent: 6578194 (2003-06-01), Baumgart et al.
patent: 6587967 (2003-07-01), Bates et al.
patent: 6678734 (2004-01-01), Haatainen et al.
patent: 6681384 (2004-01-01), Bates et al.
Title: A Sclable Architecture for Multi-threaded JAVA Applications, author: Mrva et al, IEEE, 1998.*
Title: OCM-A Monitoring System for Interoperable Tools, author: Wismuller et al, ACM, 1998.*
Title: Debugging Concurrent Programs, author: Mcdowel et al, ACM, 1989.

Affiliated with

Also associated with

Rating

Generalised program hooks does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Generalised program hooks, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Generalised program hooks will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3194154