> 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/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:27 EST