On Mon, 11 Sep 2000 16:19:14 -0600, 
"Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
>Who pays you?  

I used to work on kdb in my own time, for free.  Then I joined SGI and
now I get paid to work on it.  If I left SGI I would continue to work
on kdb, the original kdb developer left SGI but still contributes.

>> The kernel debuggers that are kept up to date get used.  The ones that
>> are used get feedback for kernel changes which keep them up to date.
>> kdb has taken off precisely because it is being kept up to date with
>> the kernel.  And if I miss something, I know that people will tell me.
>
>I'm sure this is all true.  kdb was just rejected by Linus however, what
>message does that send to you?

That Linus does not like kernel debuggers.  This is news?  There are
several examples of code that Linus did not like originally but enough
people wanted them and they eventually got included in the kernel.
Complaining to Linus does nothing, "show me the code".

>kdb is about 1/100th the size of the MANOS debugger in terms of source
>code size, and isn't a hacked in after thought like kdb.  It uses task
>gates and other tables beneath the OS that just are not there in kdb and
>that will impinge on architectural freedom for Linus.  It also uses
>nested task gates, and requires changes to the xcall layer in Linux to
>plug it in.

kdb is not a hacked in after thought.  It was designed from scratch as
a minimalist kernel debugger which coexists with the existing kernel
design.  Note "minimalist", adding kdb to a kernel has little effect on
the running kernel, the biggest impact is the symbol table (adds 20-30%
to loaded kernel size) and the last branch recording in the page fault
handler which probably slows page faulting slightly, although I have
not measured it.

kdb does a reasonable job at the binary level which is exactly what it
was designed to do.  If you have to change the kernel design to
incorporate a debugger then you seriously need to think if your
debugger design is suitable.

>If Linus doesn't support the concept, it could be a lot of
>work.  I know my code, you know yours -- Linus habit of breaking things
>as he puts in new and better features that you stated aealier is true,
>so where does that leave us?

In exactly the same position as every other kernel developer.  Nobody
promised us that kernel APIs would remain stable in development
kernels, if it breaks we fix it in the next patch.  This is the Linux
development model, everyone else lives with it.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Reply via email to