Re: [PATCH 3/4] Add SLAB allocator understanding.

[Vlastimil Babka <vbabka at suse dot cz>]

On 02/01/2016 02:21 PM, Kieran Bingham 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.

Hi,

I understand that the idea of python scripts living in the kernel tree 
looks desirable, but I see several practical drawbacks. My main goal 
with this is to have a better replacement for the crash [1] tool for 
kernel crash dump analysis. The tool supports dumps from a range of 
kernel versions, and so should the replacement. We regularly deal with 
crash dumps from 3.0-based and newer kernels, so backporting some 
kernel-version-specific python scripts to those kernel versions (or even 
older) is infeasible. Then we would have to assume that any kernel patch 
author changing a subsystem doesn't forget to update the in-kernel 
scripts, otherwise they easily get out of sync in the git history. 
Lastly, it's bit more comfortable if the only input you need is the 
dump, vmlinux and vmlinux.debug, without having to checkout scripts from 
git.

So I believe it's better if the tool could understand and work with a 
range of kernel versions by itself, like crash. The split between 
functionality in C and python is a separate question. I understand you 
wouldn't want to add all the required knowledge into gdb proper, so what 
other options are there? Some kind contrib/python/kernel directory for 
the python scripts? (but not version specific?). How can we similarly 
separate the required C code, if it turns out that doing *everything* in 
python, wrapping only the lowest-level gdb concepts would be too slow?

Thanks,
Vlastimil

[1] https://people.redhat.com/anderson/