Keith Owens wrote:
>
> On Mon, 11 Sep 2000 16:19:14 -0600,
> "Jeff V. Merkey" <jmerkey@timpanogas.com> 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.
It's good they see the value of kdb and are willing to do this. I
commend them.
>
> >> 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".
You know where the code is -- go look at it.
>
> >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.
I support source level in the kernel. Based on Andi Klein's review, I
have grabbed ext2utils and am looking at a minimal int 0x13 interface to
load files into memory. hardest problem here for Linux is having a tiny
FS that won't deadlock to load source files.
>
> 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.
I have to look at long term support. We get very busy around here and
spending money I will do if it makes sense. I do appreciate your
input.
Jeff
>
> -
> 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/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:16 EST