> I've seen there is rdbfs for debugging the 9pc kernel through a serial port...
> 
> The computer the driver fails on doesn't have a serial port. I'd like
> to the debug the ethernet driver, so I don't have ethernet. :)
> 
> Any ideas, over the common lot-of-print() ?
> 
> Thanks in advance.

yes.  we have a small embedded kernel with no user space. since
it's hard to find serial these days, serial didn't seem like the best
solution.  so we export the segments, stack and memory as aoe
targets.  this won't help in the very early phases of boot, and
requires a working ethernet driver.  but our example is about
250 lines of code.  with aoedbfs (/n/sources/contrib/quanstro/src/aoedbfs)
acid or db can be used to debug the target with acid or db.

with the plan 9 kernel, i think the right solution would be to
put the aoe debugger in 9load.  this would require the plan 9
kernel leaving  9load in core (wasting 8 mb or so) and having
a mechanism for passing control back to 9load. this mechanism
could replace doublefault() and be inserted into debugbpt
and (on the 386) fault386.

- erik

p.s. there's also a program called aoesnap in
/n/sources/contrib/quanstro/src that will take a snapshot
of a process exporting debugging via aoe.  there may be some
assumptions that are unique to our situation and the code is
somewhat convoluted due to the fact that we typically snapshot
processes using gigabytes of memory, so the image needs to be
streamed out rather than processed in a serial manner like
snap.  it also contains compatability goo so it compiles on
linux.

Reply via email to