How do *you* debug device drivers?

[Rob Warnock]

+---------------
|                                                     ... However, note
| that Rob Warnock gave a paper on this very subject at Salt Lake, and
| there is at least a summary of it in the proceedings.  His conclusion
| was that you can do a lot of debugging in user mode if you really try.
|	Henry Spencer |	{allegra,ihnp4,linus,decvax}!utzoo!henry
+---------------

As I already sent a copy to the original requestor, I will not post it
here (~200 lines) unless the demand warrents. Henry states my general
position well: You can do a lot, actually nearly all, from user mode.

CAVEAT: The devices you're trying to talk to must not permanently lose
data if you don't service them speedily. What this means is that debugging
disks, Ethernets, streamer cartridge tapes, and other block-at-a-time devices
is easy; debugging synchronous comm lines is o.k.  if you put the packet
frame level (NOT the protocol, just the frame) in the kernel and leave
the protocol in user mode; debugging speech processors is a bit harder
(but I'm doing it anyway these days). Debugging byte-at-a-time disk
controllers (like an Apple "Woz chip" controller) is asking for your
disk to be erased the first time "cron" wakes up while you have the
write gate open! ;-}

What lets user-mode debugging work in general is that IN MOST CASES
the time-critical part of the driver ("catch the interrupt") is not
the algorithmically complex part of the driver ("what do I do with
THIS frame?"), so you can separate them. Put just a stub in the kernel
to "break the interrupt latency" and work on the hard stuff in user mode.


Rob Warnock
Systems Architecture Consultant

UUCP:	{ihnp4,ucbvax!dual}!fortune!redwood!rpw3
DDD:	(415)572-2607
USPS:	510 Trinidad Lane, Foster City, CA  94404