[PATCH 3/4] Add SLAB allocator understanding.

[Doug Evans]

On Mon, Feb 1, 2016 at 5:21 AM, Kieran Bingham <kieranbingham@gmail.com> wrote:
> This is interesting work!
>
> I had been discussing how we might achieve managing this with Jan @
> FOSDEM yesterday.
>
> I believe a python implementation of this could be possible, and then
> this code can live in the Kernel, and be split across architecture
> specific layers where necessary to implement handling userspace
> application boundaries from the Kernel Awareness.

Keeping application specific code with the application instead of gdb
is definitely a worthy goal.
[one can quibble over whether linux is an application of course,
but that's just terminology]

> I believe that if properly abstracted (which I think it looks like this
> already will be), with kdump as a target layer, we can implement the
> Kernel awareness layers above, so that they can be common to all of our
> use case scenarios.
>
> I have recently proposed creating a gdb.Target object, so that we can
> layer the kernel specific code on top as a higher stratum layer. This
> code can then live in the Kernel, and be version specific there, and
> would then cooperate with the layers below, be that a live target over
> JTAG, or a virtualised qemu/kvm, or a core dump file:

Providing gdb.Target is also a worthy goal.
I hope someone will take this on.