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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
