Re: [Kgdb-bugreport] [Fwd: Re: Permanent Kgdb integration into the kernel - lets get with it.]

[Bob Picco <bob.picco@hp...>]

Sergei Shtylyov wrote:	[Tue Apr 17 2007, 02:50:39PM EDT]
> Suddenly, there's KGDB discussion in linux-kernel. :-)
> 
> -------- Original Message --------
> Subject: Re: Permanent Kgdb integration into the kernel - lets get with it.
> Date: Tue, 17 Apr 2007 20:45:03 +0200
> From: Andi Kleen <ak@...>
> Organization: SUSE Linux Products GmbH, Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg)
> To: Randy Dunlap <randy.dunlap@...>
> CC: piet@..., Tom Rini <trini@...>,	Dave Jiang <djiang@...>, linux-kernel@...,	sshtylyov@..., Andrew Morton <akpm@...>,	George Anzinger <george@...>,	"David O'Brien" <obrien@...>
> References: <20070307204516.GA24095@...> <1173392650.8912.236.camel@...> <20070417113016.1f0812c7.randy.dunlap@...>
> 
Hi:
> 
> > Is there any movement on this?
> 
> I'm open to reasonable patches for the hooks at least. If that is done
> then the actual kgdb code can be reviewed and considered eventually too. 
> 
> But just having the hooks in would make it easy enough to use anyways 
> (no patching, just dropping in of new files, or even loading of it as a
> module into any kernel)
> 
> When I did the original x86-64 kgdb port this worked nicely --
> kgdb could work with just the standard die notifiers and a simple
> change in the serial console code.
> 
> The recent kgdb seems to need much more changes again though.
> 
> However every time when I suggested this (fixing the hooks first
> and submitting the really needed changes piece by piece)
> there didn't seem to be any interest from the various kgdb maintainers.
> 
> So my impression currently is that they're not interested in merging.
> 
> Another problem is that kgdb is moving more and more away from
> mainline by adding various weird hacks and workarounds in random
> code that just make  merging harder.
> 
> Before anything could be considered for merging that all would
> need to be cleaned up.
> 
> -Andi
> 
I saw the posting on lkml too. It certainly doesn't appear to reflect
the effort in the core-lite and related patches before the core code in
the quilt series file. Sure some base files have been patched but by in large
it's minimal. We might consider some hooks that just disappear in the
absence of kgdb. For example the one in __might_sleep probably could be
addressed with:
	if (kgdb_active_in_might_sleep())
		return;

ISTR we went to great lengths to avoid base changes. We also used the
notifier chains to reduce core changes. 

I think several factors will cause us challenges. The dominant one is we have
been far too idle for normal lkml bandwidth. Thus we need a set of
patches to represent where we are at.

bob

[Kgdb-bugreport] [Fwd: Re: Permanent Kgdb integration into the kernel - lets get with it.]

[Sergei Shtylyov <sshtylyov@ru...>]

Suddenly, there's KGDB discussion in linux-kernel. :-)

-------- Original Message --------
Subject: Re: Permanent Kgdb integration into the kernel - lets get with it.
Date: Tue, 17 Apr 2007 20:45:03 +0200
From: Andi Kleen <ak@...>
Organization: SUSE Linux Products GmbH, Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg)
To: Randy Dunlap <randy.dunlap@...>
CC: piet@..., Tom Rini <trini@...>,	Dave Jiang <djiang@...>, linux-kernel@...,	sshtylyov@..., Andrew Morton <akpm@...>,	George Anzinger <george@...>,	"David O'Brien" <obrien@...>
References: <20070307204516.GA24095@...> <1173392650.8912.236.camel@...> <20070417113016.1f0812c7.randy.dunlap@...>


> Is there any movement on this?

I'm open to reasonable patches for the hooks at least. If that is done
then the actual kgdb code can be reviewed and considered eventually too. 

But just having the hooks in would make it easy enough to use anyways 
(no patching, just dropping in of new files, or even loading of it as a
module into any kernel)

When I did the original x86-64 kgdb port this worked nicely --
kgdb could work with just the standard die notifiers and a simple
change in the serial console code.

The recent kgdb seems to need much more changes again though.

However every time when I suggested this (fixing the hooks first
and submitting the really needed changes piece by piece)
there didn't seem to be any interest from the various kgdb maintainers.

So my impression currently is that they're not interested in merging.

Another problem is that kgdb is moving more and more away from
mainline by adding various weird hacks and workarounds in random
code that just make  merging harder.

Before anything could be considered for merging that all would
need to be cleaned up.

-Andi

Re: [Kgdb-bugreport] [PATCH] avoid leaving netpoll in trapping mode by KGDBoE

[Sergei Shtylyov <sshtylyov@ru...>]

Hello.

Wessel, Jason wrote:

> Given that you know of no more recent source archive than I do, which
> source repository did you want to start from,

   With linux-2.6-kgdb-testing.git as being more recent and most probably containing all our patches from the last year.

> or did you have a patch
> tree against a recent kernel that you wanted to start with instead?

   No.

> I have several starting points which can be used to go forward to the
> mainline rc candidates.  Presently I was using the linux2_6_21_uprev
> branch.  Or I can take the git archive that Tom started and merge into
> the uprev branch as well.

   That would be fine with me since it would save me quite a lot of work.

> As an example:
> http://kgdb.cvs.sourceforge.net/kgdb/kgdb-2/?pathrev=linux2_6_21_uprev
 
>>>In terms of the location for the source control, would you prefer 
>>>kernel.org git to start with,

>>  You mean creating another one?

> Yes, I mean creating something new, because at this point we have
> diverged sets of sources and this will be the best means of
> consolidating everything into one stream of patches to be contributed to
> the mainline.

>>>or updating the CVS patches in the kgdb.sourceforge.net?

>>   Well, to me patchset being kept under CVS (or git) control 
>>looks the best for now.

   Well, I meant to say one can have patchset under git as well, something like Greg KH is doing in his stable-queue.git...

>>Do you mean to use git in this way or in its usual way -- to 
>>just commit the patches to it as they arrive (and ending up 
>>with a longer patch stream)?

> If we use the git, there would be a much longer patch stream because the
> commits would accumulate, and I am ok with that.  It is easy enough to
> consolidate changes into a logical set after there is stability.

   Erm... from my experience working with other projects, it may be not so easy. :-)

> Jason.

WBR, Sergei

Re: [Kgdb-bugreport] [PATCH] avoid leaving netpoll in trapping mode by KGDBoE

[Wessel, Jason <jason.wessel@wi...>]

=20

> -----Original Message-----
> From: Sergei Shtylyov [mailto:sshtylyov@...]=20
> Wessel, Jason wrote:
> > Are there any other locations that have newer patches?
>=20
>   No.


Given that you know of no more recent source archive than I do, which
source repository did you want to start from, or did you have a patch
tree against a recent kernel that you wanted to start with instead?

I have several starting points which can be used to go forward to the
mainline rc candidates.  Presently I was using the linux2_6_21_uprev
branch.  Or I can take the git archive that Tom started and merge into
the uprev branch as well.

As an example:
http://kgdb.cvs.sourceforge.net/kgdb/kgdb-2/?pathrev=3Dlinux2_6_21_uprev

>=20
> > In terms of the location for the source control, would you prefer=20
> > kernel.org git to start with,
>=20
>   You mean creating another one?

Yes, I mean creating something new, because at this point we have
diverged sets of sources and this will be the best means of
consolidating everything into one stream of patches to be contributed to
the mainline.

>=20
> > or updating the CVS patches in the kgdb.sourceforge.net?
>=20
>    Well, to me patchset being kept under CVS (or git) control=20
> looks the best for now.
> Do you mean to use git in this way or in its usual way -- to=20
> just commit the patches to it as they arrive (and ending up=20
> with a longer patch stream)?

If we use the git, there would be a much longer patch stream because the
commits would accumulate, and I am ok with that.  It is easy enough to
consolidate changes into a logical set after there is stability.

Jason.

Re: [Kgdb-bugreport] [PATCH] avoid leaving netpoll in trapping mode by KGDBoE

[Sergei Shtylyov <sshtylyov@ru...>]

Hello.

Wessel, Jason wrote:

> I would like to setup a place that we can collaborate to complete the
> integration of KGDB into the main line kernel.  I too have many patches
> and my internal KGDB tree looks quite different than what is in CVS or
> kernel.org.  The goal here is to unify the source base.

> Are there any other locations that have newer patches?

  No.

> In terms of the location for the source control, would you prefer
> kernel.org git to start with,

  You mean creating another one?

> or updating the CVS patches in the kgdb.sourceforge.net?

   Well, to me patchset being kept under CVS (or git) control looks the best for now.
Do you mean to use git in this way or in its usual way -- to just commit the patches to it as they arrive (and ending up with a longer patch stream)?

> Thanks,
> Jason. 

>>-----Original Message-----
>>From: Sergei Shtylyov [mailto:sshtylyov@...] 
>>Sent: Monday, April 16, 2007 3:47 PM
>>To: Wessel, Jason
>>Cc: kgdb-bugreport@...; Amit S. Kale
>>Subject: Re: [Kgdb-bugreport] [PATCH] avoid leaving netpoll 
>>in trapping mode by KGDBoE
>>
>>Hello.
>>
>>Wessel, Jason wrote:
>>
>>
>>>I am not certain of the best route... So I am open to suggestions.
>>
>>>It seems that there is two separate git trees which you can see the 
>>>summary on if you are using firefox at:
>>
>>http://git.kernel.org/?p=linux/kernel/git/trini/linux-2.6-kgdb-master.
>>
>>>git;a=shortlog
>>
>>http://git.kernel.org/?p=linux/kernel/git/trini/linux-2.6-kgdb-testing
>>
>>>.git;a=summary
>>
>>>It seems that we probably want to go from the first one.
>>
>>   In fact, it still misses (at least) some MIPS changes.
>>
>>
>>>What I don't know is just how different the code in here 
>>
>>is, but I can 
>>
>>>certainly experiment to see...
>>
>>   Both these trees are already quite old, and for all this 
>>time KGDB equivalent to the testing tree have been in our 
>>internal trees, so might be worth starting with it already.

WBR, Sergei