[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
remote kernel debugging over a network
Hello, kernel hackers!
I am the student doing the "Remote kernel debugging over Ethernet"
Google Summer of Code project.
I have to make a decision about the protocol that will be used for
remote kernel debugging.
The environment for running any protocol, when the kernel is stopped for
inspection, is very limited. Normal interrupt delivery is disabled and
we can't rely on any kernel facilities.
My question is: Should I go with a custom protocol (+ a daemon that
proxies to TCP), or should I go with TCP directly?
(TCP is a necessary part, because gdb has a built-in ability to speak
its remote debug protocol over TCP.)
With a custom protocol, we can:
1) have packet based flow control, i.e. if we have 3 free RX descriptors
in the NIC receive ring, we can communicate that to the peer, so that he
doesn't send more.
2) pass over the responsibility for detecting packet loss and doing
retransmissions to the more capable peer (the one on the developer
3) we can do any other thing that comes to our mind
If we use TCP:
1) we don't need to re-invent or re-write what we already have. TCP has
flow control and retransmission. There are small TCP implementations
2) we don't need a proxy daemon. Gdb will connect directly to the kernel
Using TCP directly requires retransmission timers. We have at least
these ways to emulate timers:
1) Use delay(len) to sleep for one "tick" of length 'len', counting the
ticks and thus measuring time.
2) Continuously poll the Ethernet NIC for arriving packets, with an
external daemon providing us with tick packets every 'len' microseconds.
Every tick packet is one tick. Count the ticks and measure time that way.
So, what do you think? Custom protocol with a proxy daemon or TCP directly?
Main Index |
Thread Index |