David Etheredge wrote in a message to Peter Fitzsimmons:

 DE> Thanks, I will look into that. The only concern that I have
 DE> here about using a device driver is that I hear that a
 DE> device driver can not access other device drivers. As a
 DE> routine, we log each individual character to disk as it
 DE> comes in / goes out the com port. This is critical for
 DE> debugging field problems. 

You can have device drivers access other devices.  The requirement is that
both device drivers have to be coded to allow it, using the Inter-Device
Driver Communication (IDC) facility.

If all you want to do is log stuff out of the driver to disk, that is quite
a lot easier to do.  One approach is to write the driver to allow a device
monitor, and then write a device monitor daemon that runs at application
level on the OS/2 scheduler.  For more sophisticated functionality such as
passing data back into the driver, you can write the device driver to
expect an ancillary control process to communicate with it by IOCtl or
similar mechanisms, and then write the ancillary control process to run as
an application level daemon.  You can use context hooks in the driver to
make this a little more efficient.

There are even tricks you can do to accomplish things that are technically
unsupported.  For example, you are not supposed to be able to do IDC to a
block device driver, but you can write a single module that contains both a
character and a block device driver which share identical code and data
segments, and then you can do IDC with the character driver that has access
to the block driver's private data.  Believe me, logging is no big deal.

If what you want is the ability to debug using dumps, then you should look
at the native OS/2 system trace facility.  This allows you to define
logging events and checkpoints in your code that are recorded in a large
ring buffer by the operating system.  In the event of a crash, the trace
buffer can be written out to disk.
 
-- Mike


---