From: Maxim Levitsky
Subject: Re: [git pull] x86 arch updates for v2.6.25
Date: Feb 4, 7:36 pm 2008

On Wednesday, 30 January 2008 03:15:50 Ingo Molnar wrote:
> 
> Linus, please pull the latest x86 git tree from:
> 
>     git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
> 
> Find the shortlog attached below.
> 
> Most of the changes we have described here:
> 
>     http://lkml.org/lkml/2008/1/21/230
> 
> It's not a small merge, it consists of 908 commits from 96 individual 
> arch/x86 developers (!):
> 
>     671 files changed, 42791 insertions(+), 38967 deletions(-)
> 
> so here are a few highlevel comments as well, in addition to the 
> shortlog:
> 
> - a number of core files are changed as well: most notably percpu,
>   debugging details, timers, the firewire remote debugging patch and ...
>   the KGDB remote debugging stub in kernel/kgdb.c.
> 
> - we tested KGDB to be merge-worthy within the x86 architecture (the 
>   only supported architecture for now) and it's better to have 
>   kernel/kgdb.c than arch/x86/kernel/kgdb.c. The code is reasonably 
>   clean and the user-space exposure is small - the only real exposure is 
>   the decades-old remote GDB protocol. We are happy to fix up any 
>   further cleanliness comments that people might have - but we really 
>   wanted to start somewhere and get this thing moving. As an added 
>   bonus: finally a kernel debugger that can be read without puking too
>   much ;-) [anyone remember KDB?]
> 

The x86 tree was merged several times, but I don't see kgdb included in 
latest mainline -git.

So just one question, will it be included or no?

Best regards,
	Maxim Levitsky
--


From: Linus Torvalds
Subject: Re: [git pull] x86 arch updates for v2.6.25
Date: Feb 4, 8:27 pm 2008

On Tue, 5 Feb 2008, Maxim Levitsky wrote:
> 
> The x86 tree was merged several times, but I don't see kgdb included in 
> latest mainline -git.
> 
> So just one question, will it be included or no?

I won't even consider pulling it unless it's offered as a separate tree, 
not mixed up with other things. At that point I can give a look.

That said, I explained to Ingo why I'm not particularly interested in it. 
I don't think that "developer-centric" debugging is really even remotely 
our problem, and that I'm personally a lot more interested in 
infrastructure that helps normal users give better bug-reports. And kgdb 
isn't even _remotely_ it.

So I'd merge a patch that puts oops information (or the whole console 
printout) in the Intel management stuff in a heartbeat. That code is 
likely much grottier than any kgdb thing will ever be (Intel really 
screwed up the interface and made it some insane XML thing), but it's also 
fundamentally more important - if it means that normal users can give oops 
reports after they happened in X (or, these days, probably more commonly 
during suspend/resume) and the machine just died.

kgdb? Not so interesting. We have many more hard problems happening at 
user sites, not in developer hands.

		Linus
--

From: Phil Oester
Subject: Re: [git pull] x86 arch updates for v2.6.25
Date: Feb 4, 9:11 pm 2008

On Mon, Feb 04, 2008 at 07:27:53PM -0800, Linus Torvalds wrote:
> kgdb? Not so interesting. We have many more hard problems happening at 
> user sites, not in developer hands.

FWIW, I'm not a fulltime developer by any means, but on occasion
I have fixed a few bugs in the netfilter area of the kernel.
And in almost all cases, I used kgdb in my debugging and testing
of fixes.  

In doing so, it was a bit of a PITA to find/patch kgdb into the
kernel, and having it as a configurable option would have saved
me some time and effort and made the process much smoother.

So perhaps someone else out there would find it similarly useful,
and the extra time it takes to find/patch/compile kgdb in is
precluding them from participating?  Why would we ever want to do
that?

Phil
--


From: Andrew Morton
Subject: Re: [git pull] x86 arch updates for v2.6.25
Date: Feb 4, 9:54 pm 2008

On Mon, 4 Feb 2008 20:11:03 -0800 Phil Oester <kernel@linuxace.com> wrote:

> On Mon, Feb 04, 2008 at 07:27:53PM -0800, Linus Torvalds wrote:
> > kgdb? Not so interesting. We have many more hard problems happening at 
> > user sites, not in developer hands.
> 
> FWIW, I'm not a fulltime developer by any means, but on occasion
> I have fixed a few bugs in the netfilter area of the kernel.
> And in almost all cases, I used kgdb in my debugging and testing

                                                           ^^^^^^^
> of fixes.  

yup.

> In doing so, it was a bit of a PITA to find/patch kgdb into the
> kernel, and having it as a configurable option would have saved
> me some time and effort and made the process much smoother.
> 
> So perhaps someone else out there would find it similarly useful,
> and the extra time it takes to find/patch/compile kgdb in is
> precluding them from participating?  Why would we ever want to do
> that?

I used kgdb continuously for 4-5 years until it broke.  I don't think I
ever used it much for "debugging" as such.  I used it more for general
observation of what's going on in the kernel.  And for _confirmation_ of
what's going on (ie: testing that the actual state matches the expected
state).

I'd end up doing my development with the assumption that kgdb was present. 
One example: rather than putting printks all over the place to ensure that
the right thing was happening at the right time I'd instead add code like

void foo(void)
{
}

	...
	if (expr)
		foo();

then, when the testcase was up and running and in steady state, break in
and put a breakpoint on foo().  Continue, wait for the breakpoint then go
in and observe locals, globals, data structures, etc.

It's hard to describe (and remember!).  But the presence of the debugger as
a development (not debugging) tool changes the way you do development a bit.
--