[lkml]   [2000]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:39    [W:0.022 / U:12.288 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site