Re: [PATCH 3/4] scripts/gdb: Add rb tree iterating utilities

From: Jan Kiszka <jan.kiszka@siemens.com>
To: Stephen Boyd <swboyd@chromium.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Kieran Bingham <kbingham@kernel.org>
Cc: linux-kernel@vger.kernel.org,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Douglas Anderson <dianders@chromium.org>,
	Nikolay Borisov <n.borisov.lkml@gmail.com>,
	Jackie Liu <liuyun01@kylinos.cn>
Subject: Re: [PATCH 3/4] scripts/gdb: Add rb tree iterating utilities
Date: Tue, 26 Mar 2019 18:21:21 +0100	[thread overview]
Message-ID: <ff5bffea-2689-0ace-9c77-2aaa6605342c@siemens.com> (raw)
In-Reply-To: <155361993610.20095.762425616683725063@swboyd.mtv.corp.google.com>

On 26.03.19 18:05, Stephen Boyd wrote:
> Quoting Kieran Bingham (2019-03-26 01:52:10)
>> Hi Stephen,
>>
>> On 25/03/2019 18:45, Stephen Boyd wrote:
>>> Implement gdb functions for rb_first(), rb_last(), rb_next(), and
>>> rb_prev(). These can be useful to iterate through the kernel's red-black
>>> trees.
>>
>> I definitely approve of getting data-structure helpers into scripts/gdb,
>> as it will greatly assist debug options but my last attempt to do this
>> was with the radix-tree which I had to give up on as the internals were
>> changing rapidly and caused continuous breakage to the helpers.
> 
> Thanks for the background on radix-tree. I haven't looked at that yet,
> but I suppose I'll want to have that too at some point.
> 
>>
>> Do you foresee any similar issue here? Or is the corresponding RB code
>> in the kernel fairly 'stable'?
>>
>>
>> Please could we make sure whomever maintains the RBTree code is aware of
>> the python implementation?
>>
>> That said, MAINTAINERS doesn't actually seem to list any ownership over
>> the rb-tree code, and get_maintainers.pl [0] seems to be pointing at
>> Andrew as the probable route in for that code so perhaps that's already
>> in place :D
> 
> I don't think that the rb tree implementation is going to change. It
> feels similar to the list API. I suppose this problem of keeping things
> in sync is a more general problem than just data-structures changing.
> The only solution I can offer is to have more testing and usage of these
> scripts. Unless gdb can "simulate" or run arbitrary code for us then I
> think we're stuck reimplementing kernel internal code in gdb scripts so
> that we can get debug info out.
> 

Could we possibly leave some link in form of comment in the related headers or 
implementations? Won't magically solve the problem but at least increase changes 
that author actually read them when they start changing the C implementations.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux