Messages in this thread | | | Date | Mon, 11 Sep 2000 16:24:32 -0600 | From | "Jeff V. Merkey" <> | Subject | Re: Availability of kdb |
| |
Keith,
If you are volunteering to maintain the MANOS debugger after I hack it into Linux, then I accept. I'll give you an ftp and telnet account on vger.timpanogas.org and you can run with it.
:-)
Jeff
"Jeff V. Merkey" wrote: > > Who pays you? > > Keith Owens wrote: > > > > On Mon, 11 Sep 2000 09:46:15 -0600, > > "Jeff V. Merkey" <jmerkey@timpanogas.com> wrote: > > >Thanks Ted. I know, but a kernel debugger is one of those nasty pieaces > > >of software that can quickly get out of sync if it's maintained > > >separately from the tree -- the speed at which changes occur in Linux > > >would render it a very difficult project to maintain. > > > > Bullshit. It takes me about 30 minutes for most 2.4 kernel patches to > > see if kdb needs to be changed. A combination of a decent source > > control system (PRCS, ftp://ftp.XCF.Berkeley.EDU/pub/prcs) to merge and > > compare source branches, a little bit of Perl to standardize the patch > > and tkdiff to compare the old and new patches tells me very quickly if > > I need to release a new kdb patch. If the kernel changes might have > > affected kdb then I compile and test, 1-5 hours depending on the extent > > of the kernel changes. Most of the time I don't bother compiling. > > Who is paying for this, BTW. Who pays your salary? > > > > > 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? > > > > > >Linus' dislike of the kernel debugger concept would also > > >assure that it would not be considered in design decisions moving > > >forward, which is probably the biggest disuader in the whole debate. > > > > Irrelevant. Linus can change any kernel interface in the developing > > kernels at any time and does. Half the time this breaks existing > > kernel code, never mind external patches. But we manage to keep up to > > date with API changes. kdb is very low level, no I/O, restricted VFS > > and SMP dependencies. My biggest problem is gcc changes, not the > > kernel. > > > > >I don't spend money on things I believe are destined to fail. Until Linus > > >changes his mind, there's no point ... > > > > Destined to fail? Tell that to all the people downloading and using > > kdb and watch them laugh. > > 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. 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? > > 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/
| |