Messages in this thread |  | | Subject | Re: Availability of kdb | Date | Wed, 6 Sep 2000 21:47:59 +0100 (BST) | From | Alan Cox <> |
| |
> Apparently, if you follow the arguments, not having a kernel debugger > leads to various maladies: > - you crash when something goes wrong, and you fsck and it takes forever > and you get frustrated.
'It crashed.' [Spend hour teaching and end user to patch kdb] 'It crashed, it says foo, but this fsck took hours so I dont have time to help more'
[Bug goes unfixed for 2 months because it only happens on a revision 8 card which the maintainer doesnt]
> - people have given up on Linux kernel programming because it's too hard > and too time-consuming
Programming isnt the problem to me - its debugging. I get a lot of awful patches that have good debugging behind them. That debugging is the valuable part. I used to reach each of Andrea's patches to find out what the bug was rather than how he fixed it for example (nowdays I tend to apply his patches of course)
For things like driver debugging its the only way to work. Hardware simply does not work like the manual says and no amount of Zen contemplation will ever make you at one with a 3c905B ethernet card.
In many ways good crash dump tools and tracebacks (oopses do not count) are the valuable bit - remote gdb happens to be a passable crash dump tool
Alan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |