[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
* 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
Main Index |
Thread Index |