This is a request to merge KGDB into the mainline kernel.  

These KGDB patches are against the tip of kernel of the tree on
October 15, 2007.  I am continuing to update the for_mm branch against
the tip of the tree with the hope to merge KGDB into the kernel,
pending the review of the individual pieces.

http://git.kernel.org/?p=linux/kernel/git/jwessel/linux-2.6-kgdb.git;a=shortlog;h=for_mm


As of right now KGDB is comprised of 21 different patches adding in
the core api and docs first and then working up to add drivers and
arch specific support to KGDB.  The patches were broken down into
logical pieces for review and comments.

The intent of the KGDB patches is to unify the KGDB support across all
the architectures that elect to implement it KGDB functionality by
providing a common core and an arch specific stub.  For quite some
time there has been different features and uses of KGDB across the
most popular architectures.  Having a common core that takes care of
protocol parsing and the typical use case of software breakpoints
should eliminate the inconsistencies across the archs as well as
making it easier to add KGDB support to a new arch.

These KGDB patches include support for KGDB over ethernet and unify
the syntax and usage for setting up kgdb over rs232.

This series of KGDB patches covers the archs: i386, x86_64, ia64, arm,
mips, sh, ppc and powerpc.

After the merge of this patch set, any other arch can implement KGDB
support in the future by making use of the KGDB core by updating the
kgdb kconfig file and creating the arch specific stub.

Thanks,
Jason
-

[ message continues ]

This won't work very well.  There's a lot of review work to be done here,
and a lot of it by busy architecture maintainers.  Expecting people to do
all this review and test work late in the merge window when they're all
madly scrambling to get their bugs^Wpatches into mainline is not reasonable.
This should all have started a month ago.

So we're looking at a 2.6.25 merge for this work.  After this round of
review has settled, please upissue the patches and keep linux-arch (cc'ed
here) copied on everything, thanks.

-

[ message continues ]

It would also be nice to balance this out with the utrace merge, as both
are going to cause quite a lot of pain on the architecture side.
-

[ message continues ]

I don't think a utrace merge as in one big merge is going to happen ever.
It's just a too big patch doing too many things at once.  And the flag day
for switching all architectures over is another blocker.

-

[ message continues ]

I agree with Christoph - the fact that *all* architectures have to be
either ptrace or utrace make it very very painful.

What would be good is if some effort could be made by the utrace-
interested parties to make the transition to utrace much less painful.
For instance, I quite like the getregs/setregs abstractions, and it
looks like these *could* be self-contained in a single patch.  It
would be nice if we could move architectures over to this one a time.
Once that's in, that's one chunk of utrace merged.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-

[ message continues ]

Alexey Dobriyan had some patches to implement regsets, and these were
posted here on lkml.
-

[ message continues ]

Given that not all architecture maintainers read lkml, and they are
patches affecting all *architectures*, wouldn't it have been a good
idea if they'd copied linux-arch?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-

[ message continues ]

_If_ the code is properly bisectable, it should be possible to merge
core now and then switch architectures lazily. (If it is not
bisectable, it should be fixed).
							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-

[ message continues ]