Browse Prior Art Database

OS/2 Extended Trace Facility Disclosure Number: IPCOM000104314D
Original Publication Date: 1993-Apr-01
Included in the Prior Art Database: 2005-Mar-19
Document File: 4 page(s) / 105K

Publishing Venue


Related People

Heimsoth, DD: AUTHOR [+1]


A method is described to allow OS/2* device drivers to exceed the 63K buffer limit using the OS/2 system trace facility.

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

OS/2 Extended Trace Facility

      A method is described to allow OS/2* device drivers to exceed
the 63K buffer limit using the OS/2 system trace facility.

      Many OS/2 device drivers trace events occurring at Ring 0
privilege level in the operating system.  The OS/2 system trace
facility allows for a maximum of 63 kilobytes of raw data to be
traced.  After this limit is reached, the trace buffer wraps and
begins writing to the beginning of the buffer, thus, overwriting
previous trace records.  This is often unfortunate because the time
period before the buffer wraps is sometimes only a few seconds.

      Prior to this method, several tracing alternatives could be
employed to capture a desired event in the trace buffer.  If the
device driver could be designed in such a way to allow only selected
events to be traced, the desired trace events would likely be
included.  However, this might cause a sacrifice of detail that may
be needed later after looking at the trace, and would be made to
ensure that the desired event was traced.  Another method of trying
to ensure that the desired trace event was captured in the OS/2 trace
buffer was for a user to stand ready at the machine ready to turn
traces off by typing TRACE OFF at an OS/2 command prompt.  This
method has the obvious downfall that it is not always possible to
have a trusty user stand ready when the time period of failure is
several hours.

      To overcome the 63K limit of the OS/2 Trace facility, code can
be included in the device driver to field a DosDevIOCtl from a Ring 3
application program.

      The Ring 3 application program provides two functions in this
scheme.  First, it acts as a trigger to engage the new trace feature
by sending a DosDevIOCtl to the device driver.  Second, it provides
memory which will be used to store the trace records.  Ring 0 tracing
in a device driver is done via a call to the DEVICE HELPER service
provided by the OS/2 Kernel.  Device drivers are given the entry at
which to call the DEVICE HELPER services during the initialization
phase of the device driver.  This entry address is stored  in the
device driver data area in a location, e.g., "X", where indirect
calls to the DEVICE HELPER servic e are made.  For example, CALL X
would transfer control to the address contained at location X. After
the Ring 3 application is started and control is given to the device
driver via the DosDevIOCtl, the content of location X is saved and is
replaced by a new address.  The new address is the address of a
'DEVICE HELPER interceptor' which is a routine written to examine
which DEVICE HELPER function is desired and pass on directly to OS/2
kernel.  Upon return from the OS/2 Ker...