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/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:16 EST