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??'.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:25 EST