tech-kern archive

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

Re: remote kernel debugging over a network



        Hello.  I'd say use tcp.  Gdb already supports it, so half the work is
done.  More than that, if, in fact, you can use a small tcp implementation
inside the debugged kernel.
On Jun 5,  6:28pm, Jordan Gordeev wrote:
} Subject: 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 
} workstation).
} 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 
} available.
} 2) we don't need a proxy daemon. Gdb will connect directly to the kernel 
} being debugged.
} 
} 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?
} 
} --
} Jordan Gordeev
} 
>-- End of excerpt from Jordan Gordeev




Home | Main Index | Thread Index | Old Index