Messages in this thread |  | | Date | Mon, 11 Sep 2000 17:51:20 -0600 | From | "Jeff V. Merkey" <> | Subject | Re: Availability of kdb |
| |
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/
|  |