Kevin wrote:
rdos wrote:
How do Linux or Windows developers handle this? They can't be using printf-debugging, can they??
Yes, they can. And analysing crash dumps, I guess.
That's horrible.
Kevin wrote:
As long as only one component is new, you're good anyway. As long as you can work locally on the system, writing and debugging the network driver shouldn't be too bad. And if you have network (or serial) access, you can work remotely on things like input or storage drivers. Only if all of them are missing at the same time, it gets kind of nasty. If you want to avoid lots of reboots and printf debugging then, you'd have to find another machine where you can deal with only one of the problematic components at a time.
That's true. Still, the more possibilities you have to debug things, the faster you can solve things and the easier it gets.
Kevin wrote:
Quote:
Maybe the way to go is to implement simplified versions of the network chip drivers, and then only supporting UDP, listening for commands on a fixed port, and then sending answers with single UDP frames?
I doubt that this will be helpful unless you're actually debugging your generic TCP layer or something. If you can support UDP, the actual NIC driver should be good enough for handling everything else as well.
I wouldn't need it for debugging the TCP layer. I can do that with the kernel debugger running under the OS. Actually, most issues can be debugged with it, except for boot failures, scheduler issues, SMP issues, mode switches and crashes in IRQs. At least as long as the standard input and output works. I can run the kernel debugger over a network, but that uses the OS network card driver since it is all happening in the context of a functioning OS.
So what I had in mind was to create an application that runs on another machine on the network, and then send UDPs containing key press information, and getting back the display. That would make the "panic" debugger work even in the absence of a usable input device.