[GSoC] Remote kernel debugging over Ethernet

[Jordan Gordeev <jgordeev%dir.bg@localhost>]

Hello!
I've been looking at the list of suggested ideas for Google Summer of 
Code and one project caught my attention:

   "KGDB over Ethernet"

Adding support for remote kernel debugging over Ethernet is something 
that will have an _impact_.
However, the project is listed with "Estimated difficulty: Medium", 
while I believe it to be "Hard".
Maybe you know something, that I don't know, and want to share it? :-)

Here are some of my thoughts about the project.
There are three ways of implementing it:
* Let the kernel debugger use special debugging-oriented NIC drivers. 
Write debug version of NIC driver for each model of NIC that will be 
used for kernel debugging. This driver will support minimal 
interrupt-less operation and will not rely on any other kernel subsystem.
    A disadvantage to this approach is that new drivers have to be 
written for each NIC. However, if drivers are written for a few popular 
NIC's (e.g. Realtek and Intel 100Mbps and 1Gbps NIC's), a significant 
percentage of users will be covered. People with other NIC's can buy a 
supported NIC and install it into their computers.
* Make remote kernel debugging work with existing drivers, everything 
being run in a special mode, where interrupts are enabled, however the 
only interrupts serviced are interrupts from the NIC being used as debug 
port.
* Make it work with every NIC by using support for polling mode, which 
should be provided by the drivers as a general service.

The first implementation idea turns the task into a task of writing 
device drivers, which is difficult even for people with previous experience.
The second and third implementation ideas don't make the task to be of 
"medium" difficulty, I think.

Now something that makes the task easier: Inventing new debugging 
protocols or modifying gdb won't be needed, if the Ethernet 
kernel-debugging interface is made to emulate a serial console. GDB can 
speak its serial protocol both over serial line and over TCP. A userland 
application on the debugging host can communicate with the remotely 
debugged kernel over "proprietary" protocol while presenting to GDB a 
nice TCP stream of characters. The existing gdb remote kernel debugging 
stub in the debugged kernel will speak GDB's remote serial protocl to 
GDB, just like it does today. This is exactly how FireWire debugging in 
FreeBSD is implemented.

One important question to ask is what the *goal* of kernel debugging 
over Ethernet is. There are virtualization solutions that can be used to 
debug a kernel without hangs and crashes. Some of them can offer access 
to kernel memory while the kernel is in a very "crashed" state. What 
can't be debugged with virtualization is only 1) device drivers for real 
hardware, and 2) SMP bugs that, due to timing, are only exhibited on 
real hardware. Shouldn't virtualization be a preferred kernel debugging 
technique, leaving very few cases where real remote debugging is needed?

I invite you to join the discussion with your ideas, use cases and 
suggestions.


--
Jordan Gordeev