lkml.org 
[lkml]   [2000]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Availability of kdb

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/

\
 
 \ /
  Last update: 2005-03-22 12:41    [W:0.290 / U:0.704 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site