Data processing: software development – installation – and managem – Software program development tool – Testing or debugging
Reexamination Certificate
1999-08-16
2003-02-25
Khatri, Anil (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Testing or debugging
C717S127000, C717S128000
Reexamination Certificate
active
06526567
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to data processing systems, and more particularly to the debugging of a device driver used by such systems.
2. Description of the Related Art
Typically a data processing system will comprise a system unit including a random access memory (RAM) a read only store (ROS), a central processing unit (CPU) and a mass storage device such as a hard disk drive, all interconnected via a system bus. The system will run in conjunction with an operating system. Examples of such are AIX from the IBM Corporation and Windows 98 from the Microsoft Corporation. The operating system comprises code responsible for controlling the internal functions of the computer and most importantly for allowing the user to run application software and to access the facilities provided by the system. These include those which provide access to peripherals or hardware components, such as printers, modems, adapter cards etc.
Within the operating system resides a small portion of intensively used code known as the kernel. This provides services such as memory and I/O management etc. to application programs. A device driver is an integral part of the kernel itself and is a piece of code which the computer uses to control a peripheral component by transferring data between the kernel and that component. The driver is often intensively used by applications requiring access to a device (eg., a printer) and therefore the more time apportioned by the driver to a particular application, the less time available for its use by other programs in the system.
As the processing power and capability of computers increases, so does the expectation of users. Performance is crucial and the speed and efficiency at which device drivers operate is important.
With such intensive use, it is not uncommon for a problem to occur with the driver which needs diagnosing. In such a demanding environment, it is vital that problems are dealt with quickly and effectively. The process of diagnosing and eliminating errors from any piece of code is known as debugging. Developers have adopted a number of different approaches to this, each with varying degrees of success.
The use of formal proofs and methods is one such example. This involves comparing inputs to the program and outputs produced upon execution with the specification against which the code was tested prior to implementation. However, this is a manual and laborious process which relies upon human attention to detail and does not generate tracing at run-time. It is not therefore, possible to follow the program through its execution path and determine the point at which the problem occurs.
A number of software tools also exist, aimed at producing ‘bug free’ code. These provide an environment from within which breakpoints can be set, enabling one to halt the program at certain points during its execution and to manipulate its values in-situ. Although this method will ultimately produce working code, it is not suitable for complex programs which have time-dependencies and are performance-critical.
Programmers will also hard-code trace statements into the source in order that these are generated at run-time upon the execution of a particular logic unit. A print statement will produce valuable trace information. However, there is no means for switching this information off and this has performance overheads. This method is therefore not appropriate for time-dependent applications and furthermore, the production of such additional screen output may not be acceptable to some users.
A slight improvement upon the above process is the ability to generate run-time conditional-on trace statements. It is possible to switch trace on/off during program execution and this can be done via a boolean flag under the control of a tool external to the application. Each trace-point has an “if” expression associated with it and the flag is continually evaluated via this expression at run-time:
int XXXX {
if( use_debug_flag ) { printf(“Entering function
XXXX\n”); }
... work done by function XXXX.
if( use_debug_flag ) { printf(“Variable Y is %d”,Y); }
if( use_debug_flag ) { printf(“Event Z occurred”); }
if( use_debug_flag ) { printf(“Leaving function
XXXX\n”); }
}
However, the performance costs of such an evaluation may be unacceptable in itself, since it makes it impossible for such a program to operate optimally. Those applications which demonstrate time-dependent behaviour require a greater degree of efficiency. Such a method is nevertheless useful since it provides the user with a greater degree of dynamic control.
The ability to generate compile-time conditional-on trace statements provides yet a further improvement. The approach is similar to that described above, except that the “if” expression is replaced by the macro, #ifdef . . . #endif:
int XXXX {
#ifdef (compile_time_debug_flag )
printf(“Entering function XXXX\n”);
#endif
... work done by function XXXX.
#ifdef ( compile_time_debug_flag )
printf(“Variable Y is %d”,Y);
#endif
#ifdef( compile_time_debug_flag )
printf(“Event Z occurred”);
#endif
#ifdef( compile_time_debug_flag )
printf(“Leaving function XXXX\n”);
#endif
}
This permits compile-time evaluation and allows for the production of two versions of the code:
i) The code is optimised and no trace information output; or
ii) Trace statements are permanently on
Which of the two is produced is dependent upon the setting of the compile_time_debug_flag under the control of the build process. A setting of 0 produces no trace information i), whereas a setting of 1 results in ii) above. This method does not however, allow one to turn trace on and off dynamically. Therefore, if whilst running in “debug mode” the problem is fixed and no more trace output necessary, there is no means of stopping the information being displayed without unloading the driver and replacing it with the optimum version. This is both time-consuming and impractical.
A hybrid of “compile-time conditional-on” and “run-time conditional-on” trace statements can prove more useful. This approach will produce one version of code with no trace statements in for optimal performance and a second version of the code with run-time conditional-on trace statements. The second version permits trace to be dynamically switched on and off. There is, however, a performance overhead associated with this, since the boolean flag still has to be continually evaluated at run-time.
Such an approach provides a version of the code which can run to optimal performance, eliminating completely any tracing overheads. Furthermore, it supplies the flexibility to run a debug-version of the same piece of code when a problem has been discovered. This strategy is commonly used in applications where the overall efficiency of the code is important. However, this approach does not permit a transparent switch between the two versions of code. One device driver has to be unloaded before the other can be used. It is not therefore ideally suited for use with device drivers, since these are used intensively by applications. Additionally, they are difficult to substitute and it is frequently necessary for the system to be taken down and rebooted before a new driver can be re-loaded in place of the old one.
Whilst the AIX operating system from the IBM Corporation does permit a device driver to be removed from the kernel and re-loaded if necessary, this process is not transparent to the applications using the driver. All applications must first close the file handles associated with the device driver. Thus although there is no need to take the whole system down, continuous service is still interrupted.
From the technicians point of view, the act of closing the product d
Cobbett Michael
Duffin Paul Andrew
Wong Yuk-Lun
Cameron Douglas W.
Dougherty Anne Vachon
Khatri Anil
LandOfFree
System and method for optimizing a device driver by... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for optimizing a device driver by..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for optimizing a device driver by... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3181646