Messages in this thread | | | From | "J. Dow" <> | Subject | Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux | Date | Wed, 6 Sep 2000 06:11:41 -0700 |
| |
From: "Ingo Molnar" <mingo@elte.hu> > > 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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |