Messages in this thread |  | | Date | Wed, 6 Sep 2000 13:31:11 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: [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/
|  |