From: "Ingo Molnar" <[EMAIL PROTECTED]>
> > 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. "
I note again that the same arguement applies vis a vis printk
and desk checks with a paper and pencil. The printk leverages
the capable person's time. The kernel debugger leverages
the capable person's time. What IS this urge to be handicapped
when trying to debug the most important pieces of what gets
delivered on the distribution CDROMs. Is it, "I'm so hairy chested
that I can code with one metaphorical arm tied behind my
equally cliched back?" Rather seriously this seems to be a
rather transparent attempt to keep the old boy's club closed
rather than an attempt to get the most bang for each old boy's
hour of debugging and coding time.
Good tools do not foster bad code. People foster bad code.
The converse is also true.
> 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.
And absense of tools fosters this? I would think it would drive many
serious people off figuring it is a fancy toy regardless of how effective
it may be serving up web pages for ever and ever amen.
In that regard I enjoy my "Yes!" (with a raised "I won" fist) reactions
when I finally knock down a problem. But I have gotten older now and
realize that 16 million seconds per year is about all I get on a practical
basis for generating these moments. I want to leverage my talents
for the best chances of creating these moments and knowing these
moments are valid and not spurious. A good debugger is a very
good leveraging agent. I can cut a 2x4 with a largish pocket knife,
in theory. (I have never wasted the time.) In a pinch I have cut a
2X4 with a hand saw. I can see that if I wanted to do this for any
serious work power tools are required. The same logic seems
to fall into the programming realm.
> 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??'.
This is all motherhood and has little or nothing to do with the presence or
absense of leveraging agents. Sure a dolt will produce more doltish code
per mega disk revolution with the leveraging agent than without. On the
other extremity a guru will produce more good code per mega disk
revolution, too.
Linux's Open Source nature leverages quantities of people fairly effectively.
Some attention appears to be needed to leverage the abilities of the few
GOOD people. (And I note that a good debugger is a good way to figure
out how the code works for some people who do not visualize from written
code all that well. Since Linux documentation is little or no better than NT
documentation these people are stranded unless they can see what is
happening "in vitro".)
{^_^}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
