tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

[GSoC] Remote kernel debugging over Ethernet

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

Home | Main Index | Thread Index | Old Index