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

[Jeff Mahoney <jeffm@suse.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/2/16 8:21 AM, Petr Tesarik wrote:
> On Tue, 2 Feb 2016 08:22:25 +0100 Jan Kiszka
> <jan.kiszka@siemens.com> wrote:
> 
>> On 2016-02-02 03:05, Ales Novak wrote:
>>> On 2016-2-1 23:29, Doug Evans wrote:
>>> 
>> [...]
>>>> 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]
>>> 
>>> Yeah, you're right. Yet if we're talking about the SLAB in
>>> particular - considering with how many objects simultaneously
>>> has this subsystem to cope, I'm afraid that adding any extra
>>> overhead (e.g. the Pythonish) will be just painful.
>>> 
>>> It's a pitty that gdb cannot be extended dynamically, afaics.
>> 
>> First, don't be too sceptical before some has tried this. And
>> then there are still options for optimizations, either on the
>> language side (C extension to our Python modules, also in-kernel
>> maintained) or more efficient interfaces for gdb's Python API.
>> 
>> It's definitely worth exploring this first before adding Linux
>> kernel release specific things to gdb, which is going to be even
>> more painful to maintain.
> 
> I agree that putting Linux-specific code into the GDB main project
> is a bit unfortunate. But this indeed happens because there is no
> way to add an external module to GDB. In effect, there is little
> choice: all code must be either accepted by the (monolithic) GDB
> project, or it must be maintained as a custom out-of-tree patch.
> 
> Now, maintaining out-of-tree code is just too much pain. This is
> (in my opinion) the main reason people are so excited about Python
> scripting: it's the only available stable API that can be used to
> enhance GDB with things that do not belong to the core GDB. Plus,
> this API is incomplete (as evidenced by Jeff's patch set), and
> extending it is definitely more work than exporting existing C
> functions for use by modules, slowing down further development of
> GDB.

I only partially agree here.  Using Python to extend GDB to support
e.g. libkdumpfile would be a workaround.  I looked into it briefly and
decided against it. Extending the Python API has been an investment,
though.  Nearly everything I'm doing in the GDB code is generic.  I
really do want to have most of the functionality we have now with
crash implemented as Python modules.  Extensions in crash need to be
compiled in, written in sial, or use the grafted-on python plugin for
it.  All these options are terrible and not at all conducive to
collaborative, iterative improvement.  As we build up more
infrastructure, it becomes a lot easier for people to write quick
commands to automate a lot of the work we end up forced to do to get
crash to do what we need.

- -Jeff

- -- 
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJWsMA1AAoJEB57S2MheeWyKQYP/R2kZ2vTYWtom789eS/45FaY
mIWD8EsBlShfF+2ja8EdOHs6TYrkMEGTzjQIhoCJXttegwKY2H8/GXHfODuelaa6
pX5pPWNkV4v1G933NfOsfxJOEecdMAwM8MI+3HFl0I5cjw+/2xXhoEUg6+ZburlT
dU1lljlQwD3+wK5Q4L/w1jBebsTUKDAvJAuoHwVNFygKBkp0h6jqf310J7PfpzR/
S/gcoSsORUrla6pdPEaFAG3lFh6mqlNlaLPKF1GghP2/RdOY0f/Ud81l36Zlu5QI
D8YYtouR3qRzAf8XEV5qFMPUQDRL2c5U6JeLkJ06HxtgK44xV+l2AZar6YNezsaM
zLWyYN42x7W4DDVTrWVqgx9hkrhWYdLxavY48+n8DZncqSraM6F3YorghTfUSGnF
LutLEaBFHHURQfqFDAo8tEN8oT56YAKqRO5NOM2I9vZUdyizVaoCXov5fxiJHBpr
urq2vl8GCXQbg5QLUbR+Fj5E3XJZbe06OT7Oy48hECFRhwEotKqggcKgmJx2/v2H
dk1lLXaKI170OajZz91FVMLrOGARrWe1ZRMUa15slhIyeRUuuru7qH9jbEpBFV+b
LSpAax14+/pWKMFWZrkZglxAtj6QDfFzRz+zVCDzYHLKpO+2Jct51Oas69jL7bnl
xNsosBME7X/IsKjmIfmn
=g4Fu
-----END PGP SIGNATURE-----