Re: Permanent Kgdb integration into the kernel - lets get with it. (Dave: How do FreeBSD folks maintain the KGDB stub?)

2007-04-23 Thread Piet Delaney
On Sat, 2007-04-21 at 11:48 +0200, Andi Kleen wrote:
> > Lots of people want kgdb.  One person is famously less keen on it, but
> > we'll be able to talk him around, as long as the patches aren't daft.
> 
> The big question is if the kgdb developers seriously want mainline.
> At least in the past this definitely wasn't the case.

I haven't seen any email from kgdb developers saying they didn't want
kgdb to be part of mainline. 

Happen to have any e-mail demonstrating that? 

It's appears to me that:

1. Jason Wessel is putting a lot of effort at that right now.

2. Tom Rini worked hard at this just a few months ago.

3. George Anzinger was working hard at this a year or two
   with the mm series and as likely disappointed when it wasn't
   put into the mainline. As I recall the reason Linus gave
   was that there were two competing patches and he wanted that
   be resolved before integrating it into the mainline. So
   George worked with Amit at SourceForge over that past year
   or two and it's now integrated.

> 
> If they're not open to change requests from mainline reviewers we don't
> even need to bother to start the whole exercise.

What issue are there of have been that your referring to?

Once KGDB is part of KORG can't it's maintenance and support be
a kernel wide responsibility. If someone breaks kgdb shouldn't
that be backed out until the KORG developers fixes the problem?
Centralizing the responsibility for KGDB seems like mistake. I 
doubt the FreeBSD folks rip out the KGDB support of a kernel hacker
breaks KGDB and then leaves a group of KGDB developers to sort out
the problem. Seems it should be cough as a mm patch with Andrew tossing
out the patch if it breaks KGDB. Kgdb developers could try to give
Andrew a heads up if this occurs and he didn't notice it.

Once KGDB is integrated the maintenance should be minimal and changes
that break KGDB are likely best addressed by the developer that just
broke it. At least that what I'd think is an optimal approach. Perhaps
Dave O'Brien could tell us how the FreeBSD folks take care for KGDB.

> 
> Just putting their stuff onto korg isn't enough.

Yep, and once it's integrated into korg it should finally become
a permanent part of the kernel and I suspect maintained by all
kernel developers. New KGDB features could be developed at SourceForge
but maintaining kernel coherence seems like a global responsibility.
Like running fault injection on your code before checking it in.

Maybe I'm totally out to lunch on this; perhaps Dave O'Brien
can straighten me our if I'm wrong or the Linux kernel core
responsibility paradigm are incompatible with this.

I'd prefer Linux being just as good as NetBSD with Debugging support; 
current presentations like:

http://foss.in/2005/slides/netbsd-linux.pdf

show our current support as being much worse. Let's fix it.

You developed a kgdb proxy for Keith Owens kdb and I suspect you
would like to have KGDB being part of the kernel mainline as
long as it's done well. I doubt anyone would argue with that.
 
Perhaps it's possible to eventually setup KGDB so it can be 
debugged with kdb. Once KGDB is mainline that are plenty of
issues that can be addressed; for example taking a kernel
core dump after dropping into kgdb and having the registers
show up correctly in Dave Anderson's crash utility.

-piet

> 
> -Andi
-- 
Piet DelaneyPhone: (408) 200-5256
Blue Lane Technologies  Fax:   (408) 200-5299
10450 Bubb Rd.
Cupertino, Ca. 95014Email: [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part


Re: Permanent Kgdb integration into the kernel - lets get with it. (Dave: How do FreeBSD folks maintain the KGDB stub?)

2007-04-23 Thread Piet Delaney
On Sat, 2007-04-21 at 11:48 +0200, Andi Kleen wrote:
  Lots of people want kgdb.  One person is famously less keen on it, but
  we'll be able to talk him around, as long as the patches aren't daft.
 
 The big question is if the kgdb developers seriously want mainline.
 At least in the past this definitely wasn't the case.

I haven't seen any email from kgdb developers saying they didn't want
kgdb to be part of mainline. 

Happen to have any e-mail demonstrating that? 

It's appears to me that:

1. Jason Wessel is putting a lot of effort at that right now.

2. Tom Rini worked hard at this just a few months ago.

3. George Anzinger was working hard at this a year or two
   with the mm series and as likely disappointed when it wasn't
   put into the mainline. As I recall the reason Linus gave
   was that there were two competing patches and he wanted that
   be resolved before integrating it into the mainline. So
   George worked with Amit at SourceForge over that past year
   or two and it's now integrated.

 
 If they're not open to change requests from mainline reviewers we don't
 even need to bother to start the whole exercise.

What issue are there of have been that your referring to?

Once KGDB is part of KORG can't it's maintenance and support be
a kernel wide responsibility. If someone breaks kgdb shouldn't
that be backed out until the KORG developers fixes the problem?
Centralizing the responsibility for KGDB seems like mistake. I 
doubt the FreeBSD folks rip out the KGDB support of a kernel hacker
breaks KGDB and then leaves a group of KGDB developers to sort out
the problem. Seems it should be cough as a mm patch with Andrew tossing
out the patch if it breaks KGDB. Kgdb developers could try to give
Andrew a heads up if this occurs and he didn't notice it.

Once KGDB is integrated the maintenance should be minimal and changes
that break KGDB are likely best addressed by the developer that just
broke it. At least that what I'd think is an optimal approach. Perhaps
Dave O'Brien could tell us how the FreeBSD folks take care for KGDB.

 
 Just putting their stuff onto korg isn't enough.

Yep, and once it's integrated into korg it should finally become
a permanent part of the kernel and I suspect maintained by all
kernel developers. New KGDB features could be developed at SourceForge
but maintaining kernel coherence seems like a global responsibility.
Like running fault injection on your code before checking it in.

Maybe I'm totally out to lunch on this; perhaps Dave O'Brien
can straighten me our if I'm wrong or the Linux kernel core
responsibility paradigm are incompatible with this.

I'd prefer Linux being just as good as NetBSD with Debugging support; 
current presentations like:

http://foss.in/2005/slides/netbsd-linux.pdf

show our current support as being much worse. Let's fix it.

You developed a kgdb proxy for Keith Owens kdb and I suspect you
would like to have KGDB being part of the kernel mainline as
long as it's done well. I doubt anyone would argue with that.
 
Perhaps it's possible to eventually setup KGDB so it can be 
debugged with kdb. Once KGDB is mainline that are plenty of
issues that can be addressed; for example taking a kernel
core dump after dropping into kgdb and having the registers
show up correctly in Dave Anderson's crash utility.

-piet

 
 -Andi
-- 
Piet DelaneyPhone: (408) 200-5256
Blue Lane Technologies  Fax:   (408) 200-5299
10450 Bubb Rd.
Cupertino, Ca. 95014Email: [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part


Re: Permanent Kgdb integration into the kernel - lets get with it.

2007-04-21 Thread Andi Kleen

> Lots of people want kgdb.  One person is famously less keen on it, but
> we'll be able to talk him around, as long as the patches aren't daft.

The big question is if the kgdb developers seriously want mainline.
At least in the past this definitely wasn't the case.

If they're not open to change requests from mainline reviewers we don't
even need to bother to start the whole exercise.

Just putting their stuff onto korg isn't enough.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Permanent Kgdb integration into the kernel - lets get with it.

2007-04-21 Thread Andi Kleen

 Lots of people want kgdb.  One person is famously less keen on it, but
 we'll be able to talk him around, as long as the patches aren't daft.

The big question is if the kgdb developers seriously want mainline.
At least in the past this definitely wasn't the case.

If they're not open to change requests from mainline reviewers we don't
even need to bother to start the whole exercise.

Just putting their stuff onto korg isn't enough.

-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Permanent Kgdb integration into the kernel - lets get with it.

2007-04-20 Thread Andrew Morton
On Fri, 20 Apr 2007 15:51:35 -0700
Piet Delaney <[EMAIL PROTECTED]> wrote:

> > Is there any movement on this?
> 
> Hi Randy:
> 
> Jason Wessel <[EMAIL PROTECTED]> is currently leading yet
> another attempt at getting kgdb permanently into the kernel. Jason
> has a linux2_6_21 patch on SourceForge:
>   
> http://kgdb.cvs.sourceforge.net/kgdb/kgdb-2/8250.patch?view=log=linux2_6_21_uprev
> 
> and has been working with Sergei Shtylyov <[EMAIL PROTECTED]>
> recently on getting KGDBOE Netpoll patches that got lost around the 
> time of Tom's attempt. Just on Monday there were a dozen posting to 
> the source forge mailing list:
> 
>   
> 
> [EMAIL PROTECTED]
> 
> on this effort.

Unfortunately there doesn't seem to be anything there which I can autopull
into the -mm tree.  I'm presently set up for quilt trees in open
directories and for git trees.  I could add plain-old-gzipped-diffs or
whatever.

> I'd like to see a git repository on kernel.org that is used to update
> the mainstream kernel. Unfortunately getting accounts on kernel.org is
> next to impossible. If Jason doesn't have one yet it would be nice to
> offer him one for the kgdb developers to use. 

This seems to be to do with some silly spamfilter issue or something.  I
sent an email off-list.

> I agree with Andi that the kgdb code seems to be getting more
> complicated that needed thought I don't find the hooks offensive.
> Here I keep my kgdb hooks completely under #ifdef KGDB, so there
> is absolutely no difference to the kernel when KGDB isn't configured.

We can address that sort of thing via review: you send send the diffs out,
we read them and comment on them.  We do this 100 times a day - it is
simply a non-issue, as long as there's actually someone who has the
time/effort/inclination to push this feature to completion, which is what
kgdb has sadly lacked for the past decade or so.

> I also like having debug printks, similar to the SOCK_DEBUG() macros,
> to make it easy to watch kgdb internals in action. Ya can't run kgdb
> on itself. 
> 
> I find these blemish's a minor concern compared to the damage/lost
> of not integrating kgdb into the kernel permanently. When developers
> can't rely on using kgdb for easy development they tend to write code
> without consideration for what it's like using their code with the
> debugger. Linux is making a major headway into $100 embedded systems;
> the recent use in the Linksys WRT54GL (DD-WRT) and Engenius EOC-3220
> for example. Making kgdb easily accessible will make the viability of
> using Linux for embedded system greatly increased, IMHO. 

Lots of people want kgdb.  One person is famously less keen on it, but
we'll be able to talk him around, as long as the patches aren't daft.

> Perhaps with a bit of support from the kernel.org folks we could get
> the kgdb patch, with all of it's blemishes, into Andrews 2.6.21-rc7-mm1
> patch. Accounts on kernel.org for kgdb developers would be a modest
> effort. I find the CVS patch framework rather clumsy and would rather
> follow the KISS principle and just use git repositories like the rest
> of the kernel developers appear to be using.

Yes, a git tree on k.org is appropriate - let's make that happen.

But beware that it will need to be updated pretty reguarly, and it'll need
to be against Linux-tree-of-the-day, please.  The x86 code continues to
change at a tremendous rate (I count 204 x86 patches queued for 2.6.22),
and kgdb supports lots of other architectures too.

So whoever is signed up to maintain this will have quite a bit of messy
maintaneance to do during the getting-it-ready phase.  This will of course
be minimised by being VERY careful to mimimise the impact of the patchset
on the existing code.

And if/when it is merged, there will be quite a bit of tricky maintenance
work to do, if my experience of the kgdb stub is anything to go by.

There inevitably will be long-term low-level impact upon the arch
maintainers too.  But that's OK, because the way to merge this feature is
to put the arch-neutral core into the tree first, and to then send each
per-arch patch to the relevant arch maintainer for merging.  That way, they
get to decide whether they wish to take on the burden of participating in
its long-term maintenance.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Permanent Kgdb integration into the kernel - lets get with it.

2007-04-20 Thread Piet Delaney
On Tue, 2007-04-17 at 11:30 -0700, Randy Dunlap wrote:
> On Thu, 08 Mar 2007 14:24:10 -0800 Piet Delaney wrote:
> 
> > On Thu, 2007-03-08 at 11:49 -0700, Tom Rini wrote:
> > > On Thu, Mar 08, 2007 at 07:37:56PM +0100, Andi Kleen wrote:
> > > > On Thursday 08 March 2007 18:44, Dave Jiang wrote:
> > > > 
> > > > > In spite of kgdb, shouldn't it have that \n anyways in case some 
> > > > > other code
> > > > > gets added in the future after the macro? Or are you saying that 
> > > > > there should
> > > > > never be any code ever after that macro?
> > > > 
> > > > Sure if there is mainline code added after that macro we add the \n.
> > > > But only if it makes sense to add code there, which it didn't in kgdb.
> > > 
> > > Was that because with recent enough tools and config options there was
> > > enough annotations so GDB could finally figure out where things had
> > > stopped?  Thanks.
> > 
> > The reason Linus said he didn't allow George's kgdb mm patch to 
> > be integrating into the kernel a year or two ago was that Amit and
> > George had significantly different implementations. So Amit, Tom, 
> > George, and the rest of the kgdb development gang worked together 
> > and came up with a unified version that we now support on SourceForge. 
> > 
> > Tom rolled up a mm patch back in December for Andrew and then the
> > integration process stopped. I suggest we work together on getting
> > the kgdb patch back into the mm series and permanently into the kernel
> > like the kexec code and then we can avoid this kernel development
> > obfuscation.
> 
> Hi,
> Is there any movement on this?

Hi Randy:

Jason Wessel <[EMAIL PROTECTED]> is currently leading yet
another attempt at getting kgdb permanently into the kernel. Jason
has a linux2_6_21 patch on SourceForge:

http://kgdb.cvs.sourceforge.net/kgdb/kgdb-2/8250.patch?view=log=linux2_6_21_uprev

and has been working with Sergei Shtylyov <[EMAIL PROTECTED]>
recently on getting KGDBOE Netpoll patches that got lost around the 
time of Tom's attempt. Just on Monday there were a dozen posting to 
the source forge mailing list:



[EMAIL PROTECTED]

on this effort.

I'd like to see a git repository on kernel.org that is used to update
the mainstream kernel. Unfortunately getting accounts on kernel.org is
next to impossible. If Jason doesn't have one yet it would be nice to
offer him one for the kgdb developers to use. 

I agree with Andi that the kgdb code seems to be getting more
complicated that needed thought I don't find the hooks offensive.
Here I keep my kgdb hooks completely under #ifdef KGDB, so there
is absolutely no difference to the kernel when KGDB isn't configured.
I also like having debug printks, similar to the SOCK_DEBUG() macros,
to make it easy to watch kgdb internals in action. Ya can't run kgdb
on itself. 

I find these blemish's a minor concern compared to the damage/lost
of not integrating kgdb into the kernel permanently. When developers
can't rely on using kgdb for easy development they tend to write code
without consideration for what it's like using their code with the
debugger. Linux is making a major headway into $100 embedded systems;
the recent use in the Linksys WRT54GL (DD-WRT) and Engenius EOC-3220
for example. Making kgdb easily accessible will make the viability of
using Linux for embedded system greatly increased, IMHO. 

Perhaps with a bit of support from the kernel.org folks we could get
the kgdb patch, with all of it's blemishes, into Andrews 2.6.21-rc7-mm1
patch. Accounts on kernel.org for kgdb developers would be a modest
effort. I find the CVS patch framework rather clumsy and would rather
follow the KISS principle and just use git repositories like the rest
of the kernel developers appear to be using.

-piet

> 
> Thanks,
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
-- 
Piet DelaneyPhone: (408) 200-5256
Blue Lane Technologies  Fax:   (408) 200-5299
10450 Bubb Rd.
Cupertino, Ca. 95014Email: [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part


Re: Permanent Kgdb integration into the kernel - lets get with it.

2007-04-20 Thread Robin Holt
On Tue, Apr 17, 2007 at 08:45:03PM +0200, Andi Kleen wrote:
> 
> > 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. 

Would you be open to adding to that set of hooks the ones needed to get
KDB working as a loadable module?  Keith, would that be possible?

Thanks,
Robin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Permanent Kgdb integration into the kernel - lets get with it.

2007-04-20 Thread Robin Holt
On Tue, Apr 17, 2007 at 08:45:03PM +0200, Andi Kleen wrote:
 
  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. 

Would you be open to adding to that set of hooks the ones needed to get
KDB working as a loadable module?  Keith, would that be possible?

Thanks,
Robin
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Permanent Kgdb integration into the kernel - lets get with it.

2007-04-20 Thread Piet Delaney
On Tue, 2007-04-17 at 11:30 -0700, Randy Dunlap wrote:
 On Thu, 08 Mar 2007 14:24:10 -0800 Piet Delaney wrote:
 
  On Thu, 2007-03-08 at 11:49 -0700, Tom Rini wrote:
   On Thu, Mar 08, 2007 at 07:37:56PM +0100, Andi Kleen wrote:
On Thursday 08 March 2007 18:44, Dave Jiang wrote:

 In spite of kgdb, shouldn't it have that \n anyways in case some 
 other code
 gets added in the future after the macro? Or are you saying that 
 there should
 never be any code ever after that macro?

Sure if there is mainline code added after that macro we add the \n.
But only if it makes sense to add code there, which it didn't in kgdb.
   
   Was that because with recent enough tools and config options there was
   enough annotations so GDB could finally figure out where things had
   stopped?  Thanks.
  
  The reason Linus said he didn't allow George's kgdb mm patch to 
  be integrating into the kernel a year or two ago was that Amit and
  George had significantly different implementations. So Amit, Tom, 
  George, and the rest of the kgdb development gang worked together 
  and came up with a unified version that we now support on SourceForge. 
  
  Tom rolled up a mm patch back in December for Andrew and then the
  integration process stopped. I suggest we work together on getting
  the kgdb patch back into the mm series and permanently into the kernel
  like the kexec code and then we can avoid this kernel development
  obfuscation.
 
 Hi,
 Is there any movement on this?

Hi Randy:

Jason Wessel [EMAIL PROTECTED] is currently leading yet
another attempt at getting kgdb permanently into the kernel. Jason
has a linux2_6_21 patch on SourceForge:

http://kgdb.cvs.sourceforge.net/kgdb/kgdb-2/8250.patch?view=logpathrev=linux2_6_21_uprev

and has been working with Sergei Shtylyov [EMAIL PROTECTED]
recently on getting KGDBOE Netpoll patches that got lost around the 
time of Tom's attempt. Just on Monday there were a dozen posting to 
the source forge mailing list:



[EMAIL PROTECTED]

on this effort.

I'd like to see a git repository on kernel.org that is used to update
the mainstream kernel. Unfortunately getting accounts on kernel.org is
next to impossible. If Jason doesn't have one yet it would be nice to
offer him one for the kgdb developers to use. 

I agree with Andi that the kgdb code seems to be getting more
complicated that needed thought I don't find the hooks offensive.
Here I keep my kgdb hooks completely under #ifdef KGDB, so there
is absolutely no difference to the kernel when KGDB isn't configured.
I also like having debug printks, similar to the SOCK_DEBUG() macros,
to make it easy to watch kgdb internals in action. Ya can't run kgdb
on itself. 

I find these blemish's a minor concern compared to the damage/lost
of not integrating kgdb into the kernel permanently. When developers
can't rely on using kgdb for easy development they tend to write code
without consideration for what it's like using their code with the
debugger. Linux is making a major headway into $100 embedded systems;
the recent use in the Linksys WRT54GL (DD-WRT) and Engenius EOC-3220
for example. Making kgdb easily accessible will make the viability of
using Linux for embedded system greatly increased, IMHO. 

Perhaps with a bit of support from the kernel.org folks we could get
the kgdb patch, with all of it's blemishes, into Andrews 2.6.21-rc7-mm1
patch. Accounts on kernel.org for kgdb developers would be a modest
effort. I find the CVS patch framework rather clumsy and would rather
follow the KISS principle and just use git repositories like the rest
of the kernel developers appear to be using.

-piet

 
 Thanks,
 ---
 ~Randy
 *** Remember to use Documentation/SubmitChecklist when testing your code ***
-- 
Piet DelaneyPhone: (408) 200-5256
Blue Lane Technologies  Fax:   (408) 200-5299
10450 Bubb Rd.
Cupertino, Ca. 95014Email: [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part


Re: Permanent Kgdb integration into the kernel - lets get with it.

2007-04-20 Thread Andrew Morton
On Fri, 20 Apr 2007 15:51:35 -0700
Piet Delaney [EMAIL PROTECTED] wrote:

  Is there any movement on this?
 
 Hi Randy:
 
 Jason Wessel [EMAIL PROTECTED] is currently leading yet
 another attempt at getting kgdb permanently into the kernel. Jason
 has a linux2_6_21 patch on SourceForge:
   
 http://kgdb.cvs.sourceforge.net/kgdb/kgdb-2/8250.patch?view=logpathrev=linux2_6_21_uprev
 
 and has been working with Sergei Shtylyov [EMAIL PROTECTED]
 recently on getting KGDBOE Netpoll patches that got lost around the 
 time of Tom's attempt. Just on Monday there were a dozen posting to 
 the source forge mailing list:
 
   
 
 [EMAIL PROTECTED]
 
 on this effort.

Unfortunately there doesn't seem to be anything there which I can autopull
into the -mm tree.  I'm presently set up for quilt trees in open
directories and for git trees.  I could add plain-old-gzipped-diffs or
whatever.

 I'd like to see a git repository on kernel.org that is used to update
 the mainstream kernel. Unfortunately getting accounts on kernel.org is
 next to impossible. If Jason doesn't have one yet it would be nice to
 offer him one for the kgdb developers to use. 

This seems to be to do with some silly spamfilter issue or something.  I
sent an email off-list.

 I agree with Andi that the kgdb code seems to be getting more
 complicated that needed thought I don't find the hooks offensive.
 Here I keep my kgdb hooks completely under #ifdef KGDB, so there
 is absolutely no difference to the kernel when KGDB isn't configured.

We can address that sort of thing via review: you send send the diffs out,
we read them and comment on them.  We do this 100 times a day - it is
simply a non-issue, as long as there's actually someone who has the
time/effort/inclination to push this feature to completion, which is what
kgdb has sadly lacked for the past decade or so.

 I also like having debug printks, similar to the SOCK_DEBUG() macros,
 to make it easy to watch kgdb internals in action. Ya can't run kgdb
 on itself. 
 
 I find these blemish's a minor concern compared to the damage/lost
 of not integrating kgdb into the kernel permanently. When developers
 can't rely on using kgdb for easy development they tend to write code
 without consideration for what it's like using their code with the
 debugger. Linux is making a major headway into $100 embedded systems;
 the recent use in the Linksys WRT54GL (DD-WRT) and Engenius EOC-3220
 for example. Making kgdb easily accessible will make the viability of
 using Linux for embedded system greatly increased, IMHO. 

Lots of people want kgdb.  One person is famously less keen on it, but
we'll be able to talk him around, as long as the patches aren't daft.

 Perhaps with a bit of support from the kernel.org folks we could get
 the kgdb patch, with all of it's blemishes, into Andrews 2.6.21-rc7-mm1
 patch. Accounts on kernel.org for kgdb developers would be a modest
 effort. I find the CVS patch framework rather clumsy and would rather
 follow the KISS principle and just use git repositories like the rest
 of the kernel developers appear to be using.

Yes, a git tree on k.org is appropriate - let's make that happen.

But beware that it will need to be updated pretty reguarly, and it'll need
to be against Linux-tree-of-the-day, please.  The x86 code continues to
change at a tremendous rate (I count 204 x86 patches queued for 2.6.22),
and kgdb supports lots of other architectures too.

So whoever is signed up to maintain this will have quite a bit of messy
maintaneance to do during the getting-it-ready phase.  This will of course
be minimised by being VERY careful to mimimise the impact of the patchset
on the existing code.

And if/when it is merged, there will be quite a bit of tricky maintenance
work to do, if my experience of the kgdb stub is anything to go by.

There inevitably will be long-term low-level impact upon the arch
maintainers too.  But that's OK, because the way to merge this feature is
to put the arch-neutral core into the tree first, and to then send each
per-arch patch to the relevant arch maintainer for merging.  That way, they
get to decide whether they wish to take on the burden of participating in
its long-term maintenance.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Permanent Kgdb integration into the kernel - lets get with it.

2007-04-17 Thread Jason Wessel

Andi Kleen wrote:

> 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
  

Andi,

I too am open to having a API, for KGDB, but it does need more than just 
the trap vectors and the serial driver as hook points. There are a 
number of patches to fix problems randing from the NET_POLL API, NMI 
handling, and saving a bit more information when loading kernel modules.


If you have an API, that you would like to contribute or suggest, I for 
one am interested. I have long thought it would be nice to be able to 
choose between kernel debug tools KDB, KGDB, KEXEC etc... much like you 
can dynamically load I/O modules in KGDB and choose either RS232 or 
Ethernet after the kernel has booted.


At the current time, I am most certainly trying to consolidate the 
source forge KGDB patches, Tom Rini's branch, as well as my own 
development branch and hopefully Sergei's development branch as well. 
Perhaps after the code stream is stable you we can take a further look 
at what it takes to abstract a generic kernel debug interface. In the 
mean time if you have code or skeleton API proposal, I am definitely 
listening. It would be nice to have an in kernel soft single step API as 
an example, which could be leveraged by KGDB and utrace/ptrace, but that 
is a bit forward looking at this point.


Jason.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Permanent Kgdb integration into the kernel - lets get with it.

2007-04-17 Thread Andi Kleen
> I too am open to having a API, for KGDB, but it does need more than just 
> the trap vectors and the serial driver as hook points. There are a 
> number of patches to fix problems randing from the NET_POLL API, NMI 
> handling, 

You should submit these changes all as you fix them to the relevant
maintainers and mailing lists. There is only limited review capacity
and sending too many may tax it too much. So it's best used spaced
out -- as you do them. Also then you probably still remember why
you actually changed something. The few kgdb that were submitted
ever usually had the problem that they were submitted by someone
else who didn't do the work and couldn't quite remember why they
were actually needed.  Unsurprisingly they often didn't get
merged then.

> If you have an API, that you would like to contribute or suggest, I for 

The main interface are the (somewhat misnamed) die chains. More and more 
architectures are moving to them. 

There probably needs to be another one for serial intercept, but that 
should be very simple.  For network netpoll already exists.

> one am interested. I have long thought it would be nice to be able to 
> choose between kernel debug tools KDB, KGDB, KEXEC etc... much like you 
> can dynamically load I/O modules in KGDB and choose either RS232 or 
> Ethernet after the kernel has booted.

At some point we had a fully modular kdb (modprobe kdb worked) 
and kgdb was nearly there. Unfortunately the changes for kdb were
somewhat ugly. Unfortunately that work never hit the standard
patchkits for kgdb/kdb.

> At the current time, I am most certainly trying to consolidate the 
> source forge KGDB patches, Tom Rini's branch, as well as my own 
> development branch and hopefully Sergei's development branch as well. 
> Perhaps after the code stream is stable you we can take a further look 
> at what it takes to abstract a generic kernel debug interface. In the 

There already is one. I don't see the need for another one.

> mean time if you have code or skeleton API proposal, I am definitely 
> listening. It would be nice to have an in kernel soft single step API as 
> an example, which could be leveraged by KGDB and utrace/ptrace, but that 
> is a bit forward looking at this point.

kprobes already do that fine with the existing interfaces. Also
single stepping is not particularly complicated so i don't see why
you want to abstract it.

The other issue that needed some changes was stopping all CPUs for
debugging. Since some other subsystems (like kexec) have this problem
already i would suggest generalizing and exporting what they have already.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Permanent Kgdb integration into the kernel - lets get with it.

2007-04-17 Thread Andi Kleen

> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Permanent Kgdb integration into the kernel - lets get with it.

2007-04-17 Thread Sergei Shtylyov

Randy Dunlap wrote:

In spite of kgdb, shouldn't it have that \n anyways in case some 
other code
gets added in the future after the macro? Or are you saying that 
there should

never be any code ever after that macro?



Sure if there is mainline code added after that macro we add the \n.
But only if it makes sense to add code there, which it didn't in 
kgdb.



Was that because with recent enough tools and config options there was
enough annotations so GDB could finally figure out where things had
stopped?  Thanks.


The reason Linus said he didn't allow George's kgdb mm patch to be 
integrating into the kernel a year or two ago was that Amit and
George had significantly different implementations. So Amit, Tom, 
George, and the rest of the kgdb development gang worked together 
and came up with a unified version that we now support on SourceForge. 



Tom rolled up a mm patch back in December for Andrew and then the
integration process stopped. I suggest we work together on getting
the kgdb patch back into the mm series and permanently into the kernel
like the kexec code and then we can avoid this kernel development
obfuscation.



Hi,
Is there any movement on this?


  Jason Wessel has taken up KGDB maintenance for upstream. We're now 
working on merging the several diverse trees together.



at kgdb.sf.net or where is the work being done?


  Currently, 2.6.21 branch is in SF CVS but unfortunately it's not yet in sync 
with (abandoned) Tom Rini's trees.


Thanks,


WBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Permanent Kgdb integration into the kernel - lets get with it.

2007-04-17 Thread Randy Dunlap

Sergei Shtylyov wrote:

Hello.

Randy Dunlap wrote:

In spite of kgdb, shouldn't it have that \n anyways in case some 
other code
gets added in the future after the macro? Or are you saying that 
there should

never be any code ever after that macro?


Sure if there is mainline code added after that macro we add the \n.
But only if it makes sense to add code there, which it didn't in kgdb.



Was that because with recent enough tools and config options there was
enough annotations so GDB could finally figure out where things had
stopped?  Thanks.


The reason Linus said he didn't allow George's kgdb mm patch to be 
integrating into the kernel a year or two ago was that Amit and
George had significantly different implementations. So Amit, Tom, 
George, and the rest of the kgdb development gang worked together and 
came up with a unified version that we now support on SourceForge. 



Tom rolled up a mm patch back in December for Andrew and then the
integration process stopped. I suggest we work together on getting
the kgdb patch back into the mm series and permanently into the kernel
like the kexec code and then we can avoid this kernel development
obfuscation.



Hi,
Is there any movement on this?


  Jason Wessel has taken up KGDB maintenance for upstream. We're now 
working on merging the several diverse trees together.


WBR, Sergei


at kgdb.sf.net or where is the work being done?

Thanks,
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Permanent Kgdb integration into the kernel - lets get with it.

2007-04-17 Thread Sergei Shtylyov

Hello.

Randy Dunlap wrote:


In spite of kgdb, shouldn't it have that \n anyways in case some other code
gets added in the future after the macro? Or are you saying that there should
never be any code ever after that macro?


Sure if there is mainline code added after that macro we add the \n.
But only if it makes sense to add code there, which it didn't in kgdb.



Was that because with recent enough tools and config options there was
enough annotations so GDB could finally figure out where things had
stopped?  Thanks.


The reason Linus said he didn't allow George's kgdb mm patch to 
be integrating into the kernel a year or two ago was that Amit and
George had significantly different implementations. So Amit, Tom, 
George, and the rest of the kgdb development gang worked together 
and came up with a unified version that we now support on SourceForge. 



Tom rolled up a mm patch back in December for Andrew and then the
integration process stopped. I suggest we work together on getting
the kgdb patch back into the mm series and permanently into the kernel
like the kexec code and then we can avoid this kernel development
obfuscation.



Hi,
Is there any movement on this?


  Jason Wessel has taken up KGDB maintenance for upstream. We're now working on 
merging the several diverse trees together.

WBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Permanent Kgdb integration into the kernel - lets get with it.

2007-04-17 Thread Randy Dunlap
On Thu, 08 Mar 2007 14:24:10 -0800 Piet Delaney wrote:

> On Thu, 2007-03-08 at 11:49 -0700, Tom Rini wrote:
> > On Thu, Mar 08, 2007 at 07:37:56PM +0100, Andi Kleen wrote:
> > > On Thursday 08 March 2007 18:44, Dave Jiang wrote:
> > > 
> > > > In spite of kgdb, shouldn't it have that \n anyways in case some other 
> > > > code
> > > > gets added in the future after the macro? Or are you saying that there 
> > > > should
> > > > never be any code ever after that macro?
> > > 
> > > Sure if there is mainline code added after that macro we add the \n.
> > > But only if it makes sense to add code there, which it didn't in kgdb.
> > 
> > Was that because with recent enough tools and config options there was
> > enough annotations so GDB could finally figure out where things had
> > stopped?  Thanks.
> 
> The reason Linus said he didn't allow George's kgdb mm patch to 
> be integrating into the kernel a year or two ago was that Amit and
> George had significantly different implementations. So Amit, Tom, 
> George, and the rest of the kgdb development gang worked together 
> and came up with a unified version that we now support on SourceForge. 
> 
> Tom rolled up a mm patch back in December for Andrew and then the
> integration process stopped. I suggest we work together on getting
> the kgdb patch back into the mm series and permanently into the kernel
> like the kexec code and then we can avoid this kernel development
> obfuscation.

Hi,
Is there any movement on this?

Thanks,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Permanent Kgdb integration into the kernel - lets get with it.

2007-04-17 Thread Randy Dunlap
On Thu, 08 Mar 2007 14:24:10 -0800 Piet Delaney wrote:

 On Thu, 2007-03-08 at 11:49 -0700, Tom Rini wrote:
  On Thu, Mar 08, 2007 at 07:37:56PM +0100, Andi Kleen wrote:
   On Thursday 08 March 2007 18:44, Dave Jiang wrote:
   
In spite of kgdb, shouldn't it have that \n anyways in case some other 
code
gets added in the future after the macro? Or are you saying that there 
should
never be any code ever after that macro?
   
   Sure if there is mainline code added after that macro we add the \n.
   But only if it makes sense to add code there, which it didn't in kgdb.
  
  Was that because with recent enough tools and config options there was
  enough annotations so GDB could finally figure out where things had
  stopped?  Thanks.
 
 The reason Linus said he didn't allow George's kgdb mm patch to 
 be integrating into the kernel a year or two ago was that Amit and
 George had significantly different implementations. So Amit, Tom, 
 George, and the rest of the kgdb development gang worked together 
 and came up with a unified version that we now support on SourceForge. 
 
 Tom rolled up a mm patch back in December for Andrew and then the
 integration process stopped. I suggest we work together on getting
 the kgdb patch back into the mm series and permanently into the kernel
 like the kexec code and then we can avoid this kernel development
 obfuscation.

Hi,
Is there any movement on this?

Thanks,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Permanent Kgdb integration into the kernel - lets get with it.

2007-04-17 Thread Sergei Shtylyov

Hello.

Randy Dunlap wrote:


In spite of kgdb, shouldn't it have that \n anyways in case some other code
gets added in the future after the macro? Or are you saying that there should
never be any code ever after that macro?


Sure if there is mainline code added after that macro we add the \n.
But only if it makes sense to add code there, which it didn't in kgdb.



Was that because with recent enough tools and config options there was
enough annotations so GDB could finally figure out where things had
stopped?  Thanks.


The reason Linus said he didn't allow George's kgdb mm patch to 
be integrating into the kernel a year or two ago was that Amit and
George had significantly different implementations. So Amit, Tom, 
George, and the rest of the kgdb development gang worked together 
and came up with a unified version that we now support on SourceForge. 



Tom rolled up a mm patch back in December for Andrew and then the
integration process stopped. I suggest we work together on getting
the kgdb patch back into the mm series and permanently into the kernel
like the kexec code and then we can avoid this kernel development
obfuscation.



Hi,
Is there any movement on this?


  Jason Wessel has taken up KGDB maintenance for upstream. We're now working on 
merging the several diverse trees together.

WBR, Sergei
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Permanent Kgdb integration into the kernel - lets get with it.

2007-04-17 Thread Randy Dunlap

Sergei Shtylyov wrote:

Hello.

Randy Dunlap wrote:

In spite of kgdb, shouldn't it have that \n anyways in case some 
other code
gets added in the future after the macro? Or are you saying that 
there should

never be any code ever after that macro?


Sure if there is mainline code added after that macro we add the \n.
But only if it makes sense to add code there, which it didn't in kgdb.



Was that because with recent enough tools and config options there was
enough annotations so GDB could finally figure out where things had
stopped?  Thanks.


The reason Linus said he didn't allow George's kgdb mm patch to be 
integrating into the kernel a year or two ago was that Amit and
George had significantly different implementations. So Amit, Tom, 
George, and the rest of the kgdb development gang worked together and 
came up with a unified version that we now support on SourceForge. 



Tom rolled up a mm patch back in December for Andrew and then the
integration process stopped. I suggest we work together on getting
the kgdb patch back into the mm series and permanently into the kernel
like the kexec code and then we can avoid this kernel development
obfuscation.



Hi,
Is there any movement on this?


  Jason Wessel has taken up KGDB maintenance for upstream. We're now 
working on merging the several diverse trees together.


WBR, Sergei


at kgdb.sf.net or where is the work being done?

Thanks,
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Permanent Kgdb integration into the kernel - lets get with it.

2007-04-17 Thread Sergei Shtylyov

Randy Dunlap wrote:

In spite of kgdb, shouldn't it have that \n anyways in case some 
other code
gets added in the future after the macro? Or are you saying that 
there should

never be any code ever after that macro?



Sure if there is mainline code added after that macro we add the \n.
But only if it makes sense to add code there, which it didn't in 
kgdb.



Was that because with recent enough tools and config options there was
enough annotations so GDB could finally figure out where things had
stopped?  Thanks.


The reason Linus said he didn't allow George's kgdb mm patch to be 
integrating into the kernel a year or two ago was that Amit and
George had significantly different implementations. So Amit, Tom, 
George, and the rest of the kgdb development gang worked together 
and came up with a unified version that we now support on SourceForge. 



Tom rolled up a mm patch back in December for Andrew and then the
integration process stopped. I suggest we work together on getting
the kgdb patch back into the mm series and permanently into the kernel
like the kexec code and then we can avoid this kernel development
obfuscation.



Hi,
Is there any movement on this?


  Jason Wessel has taken up KGDB maintenance for upstream. We're now 
working on merging the several diverse trees together.



at kgdb.sf.net or where is the work being done?


  Currently, 2.6.21 branch is in SF CVS but unfortunately it's not yet in sync 
with (abandoned) Tom Rini's trees.


Thanks,


WBR, Sergei
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Permanent Kgdb integration into the kernel - lets get with it.

2007-04-17 Thread Andi Kleen

 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Permanent Kgdb integration into the kernel - lets get with it.

2007-04-17 Thread Andi Kleen
 I too am open to having a API, for KGDB, but it does need more than just 
 the trap vectors and the serial driver as hook points. There are a 
 number of patches to fix problems randing from the NET_POLL API, NMI 
 handling, 

You should submit these changes all as you fix them to the relevant
maintainers and mailing lists. There is only limited review capacity
and sending too many may tax it too much. So it's best used spaced
out -- as you do them. Also then you probably still remember why
you actually changed something. The few kgdb that were submitted
ever usually had the problem that they were submitted by someone
else who didn't do the work and couldn't quite remember why they
were actually needed.  Unsurprisingly they often didn't get
merged then.

 If you have an API, that you would like to contribute or suggest, I for 

The main interface are the (somewhat misnamed) die chains. More and more 
architectures are moving to them. 

There probably needs to be another one for serial intercept, but that 
should be very simple.  For network netpoll already exists.

 one am interested. I have long thought it would be nice to be able to 
 choose between kernel debug tools KDB, KGDB, KEXEC etc... much like you 
 can dynamically load I/O modules in KGDB and choose either RS232 or 
 Ethernet after the kernel has booted.

At some point we had a fully modular kdb (modprobe kdb worked) 
and kgdb was nearly there. Unfortunately the changes for kdb were
somewhat ugly. Unfortunately that work never hit the standard
patchkits for kgdb/kdb.

 At the current time, I am most certainly trying to consolidate the 
 source forge KGDB patches, Tom Rini's branch, as well as my own 
 development branch and hopefully Sergei's development branch as well. 
 Perhaps after the code stream is stable you we can take a further look 
 at what it takes to abstract a generic kernel debug interface. In the 

There already is one. I don't see the need for another one.

 mean time if you have code or skeleton API proposal, I am definitely 
 listening. It would be nice to have an in kernel soft single step API as 
 an example, which could be leveraged by KGDB and utrace/ptrace, but that 
 is a bit forward looking at this point.

kprobes already do that fine with the existing interfaces. Also
single stepping is not particularly complicated so i don't see why
you want to abstract it.

The other issue that needed some changes was stopping all CPUs for
debugging. Since some other subsystems (like kexec) have this problem
already i would suggest generalizing and exporting what they have already.

-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Permanent Kgdb integration into the kernel - lets get with it.

2007-04-17 Thread Jason Wessel

Andi Kleen wrote:

 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
  

Andi,

I too am open to having a API, for KGDB, but it does need more than just 
the trap vectors and the serial driver as hook points. There are a 
number of patches to fix problems randing from the NET_POLL API, NMI 
handling, and saving a bit more information when loading kernel modules.


If you have an API, that you would like to contribute or suggest, I for 
one am interested. I have long thought it would be nice to be able to 
choose between kernel debug tools KDB, KGDB, KEXEC etc... much like you 
can dynamically load I/O modules in KGDB and choose either RS232 or 
Ethernet after the kernel has booted.


At the current time, I am most certainly trying to consolidate the 
source forge KGDB patches, Tom Rini's branch, as well as my own 
development branch and hopefully Sergei's development branch as well. 
Perhaps after the code stream is stable you we can take a further look 
at what it takes to abstract a generic kernel debug interface. In the 
mean time if you have code or skeleton API proposal, I am definitely 
listening. It would be nice to have an in kernel soft single step API as 
an example, which could be leveraged by KGDB and utrace/ptrace, but that 
is a bit forward looking at this point.


Jason.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/