Messages in this thread | | | Date | Wed, 6 Sep 2000 14:34:48 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux |
| |
On Wed, 6 Sep 2000, J. Dow wrote:
> If the Kernel Debugger creates faulty solutions through lack of > thinking, and asking why, then surely printk is at least as bad > because it allows somebody to view the operation of the kernel through > a keyhole darkly. [...]
i'd like to quote David here, because i cannot put it any simpler:
" It is hoped that because it isn't the default, some new people will take the quantum leap to actually try debugging using the best debugger any of us have, our brains, instead of relying on automated tools. "
my claim (which others share) is that we need more people who can debug the really tough problems (for which there are no tools in any OS) with their brains, and also we need people who will produce code with less bugs in the future.
There is also the important question of 'bug prevention'. The kernel isnt some magical soup which must be debugged only, code is *added* and debugged. If people who write code use more code reviews to fix bugs, then as a side-effect they'll sooner or later write code that is less prone to bugs. This is because they identify the bug-risks based on the code pattern - if you use a debugger mainly then you dont really see the code pattern but the current state of the system, which you validate. So the difference is this:
- compare code, algorithm and concept with the original intention; analyze the symptoms and find the bug
- compare the system state discovered through the debugger with the intended state of the system. Potentially step through the code before and after the faulty behavior, try to identify the 'point of bug' and constantly compare actual system state with intended system state. (it's certainly more complex than this, but you get the point.) This is why tools/features visualizing system state are so popular.
i claim that the second behavior is 'passive', 'disconnected' and has no connection to the code itself, and thus tends to lead to inferior code. It leads to the frequent behavior of 'patching the state', not modifying the code itself. Eg. 'ok, we have a NULL here, lets return then so it wont crash later in the function.'
The first behavior IMO produces a more 'integrated' coding style, where designing, writing and debugging code is closely interwoven, and naturally leads to higher quality code. Eg. 'we must never get a NULL here, who called this function and why??'.
Ingo
- 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/
| |