lkml.org 
[lkml]   [2000]   [Sep]   [6]   [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 for Linux

On Tue, 5 Sep 2000, Richard Gooch wrote:

> Would you classify IKD as a pile of warts you wouldn't want to see in
> the kernel?

the quality of IKD is IMO excellent (<plug> having written parts of it),
yet i wouldnt want to see it in the kernel. That having said, i *did*
author and integrate one of the IKD subsystems into the mainstream kernel
- the NMI oopser on SMP systems. If a debugging aid is localized then
there are no source-code health issues. In the case of the NMI-oopser the
case was even clearer: nor a developer, nor a user can do anything useful
with a hard lockup, apart from complaining that it 'locked up'. We clearly
needed more information than that.

KDB is not a code health issue either, it's quite localized. But KDB has
the other bad social side-effect David was talking about, it promotes
band-aids. So it's a tough call IMO.

but the other IKD components, like the soft lockup detector, kernel
tracer, leak detector and other goodies, are clearly intrusive. It's
also a pain (and distraction) to 'drag' all that functionality along
in a developer kernel - i'm sure Mike can attest to that, IDK is
frequently broken by lowlevel changes.

> Surely there must be some useful features that can be included in the
> kernel without uglyfing it or slowing it down (configed
> out)? [...]

sure, and we have a number of them included already. And we rutinely
include debugging facilities along newly rewritten code (witness the
spinlock debugging helpers, the waitqueue and highmem debugging helpers,
the io.h debugging helper). These things do get removed rutinely though.
(maybe except the spinlock.h stuff - IMO we still have too much flux in
the SMP code.)

it's always a matter of balancing - we have multiple conflicting
requirements. One factor in judging a debugging facility is the frequency
and difficulty of bugs it detects. If a bug doesnt happen often and is
easy to analyze then we need no debugging facility for it. Another factor
is the impact of the patch on the kernel proper - memleak for example is
extremely intrusive. Yet another factor is the maintainance 'drag' on the
generic kernel (this is an issue even if the subsystem itself is
localized) - eg. the mcount() debugging aids (on which several IKD
features are based) periodically caused merging problems in the x86 arch,
and they will continue causing problems once we implement fast-syscalls on
x86. I'm happy that Mike and Andrea are maintaining IKD - but we dont want
to force this maintainance overhead on Linus. Plus the social factors
mentioned by David and Alexander. There are easy decisions and there are
hard decisions. KDB is IMO not an easy call.

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/

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