lkml.org 
[lkml]   [2000]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

Ingo,

Your arguments are personal, not technical. Which billiob dollar
company did you support with 70 million customers exactly? Not having
this out in the field makes folks jobs 100 times harder and more costly
for companies to support. When and if you ever run your own business,
you'll understand these things.

Jeff

Ingo Molnar wrote:
>
> On Tue, 5 Sep 2000, Andi Kleen wrote:
>
> > I don't really believe that. It is as easy to add a silly NULL pointer
> > check based on a oops as it is after a debugging session (and it is
> > even likely you chose the simple fix because it is harder and more
> > work to proceed) Usually with the debugger it is at least easier to
> > collect the data needed for a real fix. [...]
>
> this is the conceptual difference David tried to show, and which view i
> support as well. There are two basic types of 'debugging behaviors':
>
> A) 'Collect enough data to understand the local context and fix the bug.'
>
> B) 'See the point of the immediate crash, think about that code, think
> about code that called this code, think about the intent and
> implementation of that code and find the bug based on
> understanding the code.'
>
> A) results in people being able to debug easy and moderate kernel bugs.
> The same people are lost if faced with bugs that are not apparent in the
> 'state of the system around the bug' represented by the debugger.
>
> B) results in people with the ability to identify bugs based on the source
> code - and the ability to fix the really mindblowing tough bugs. We had
> about 10 such bugs during the cycle of the 2.3 kernel.
>
> I do claim that the real mainsteam-kernel development 'bottleneck' is the
> ability to fix the tough bugs. It's always these tough bugs that keep up
> the addition of new features in devel kernels. We should thus do
> everything to teach people the proper debugging methodology.
>
> A) takes less time for the easy bugs - it might also speed up driver
> development. But it is utterly useless for the really tough problems. We
> had really tough bugs in 2.3 that one couldnt find even with the heaviest
> hitting debugging equipment. Debugging code in the kernel also blurs the
> intention of the code, which makes B) harder.
>
> B) is a slower process to both learn and practice, but will also lead to
> more (unrelated) code improvements (based on better understanding of
> various kernel subsystems) and ultimately leads to better kernel
> developers.
>
> one problem is developer laziness ;-) We could as well include debugging
> code so that experienced people like you can fix easy / moderate bugs
> quicker. But the problem is that in this case people are not forced to
> understand the code as much as if the debugging tools were 'minimalistic'
> like today.
>
> i have nothing against (in fact contributed to) independent debugging
> functionality like IKD / KDB. It's slightly more pain to keep it uptodate
> with the devel kernel, but the devel kernel itself must stay focused on
> the strategic goals, not the tactical ones.
>
> 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/
-
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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.204 / U:0.168 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site