Message-ID: <c170414c-f3a0-46cb-9bce-7277a8496172@siemens.com>
Date: Thu, 26 Jun 2025 18:48:06 +0200
From: Jan Kiszka <jan.kiszka@...mens.com>
To: "Liam R. Howlett" <Liam.Howlett@...cle.com>,
 Florian Fainelli <florian.fainelli@...adcom.com>,
 linux-kernel@...r.kernel.org, Kieran Bingham <kbingham@...nel.org>,
 Michael Turquette <mturquette@...libre.com>, Stephen Boyd
 <sboyd@...nel.org>, Dennis Zhou <dennis@...nel.org>,
 Tejun Heo <tj@...nel.org>, Christoph Lameter <cl@...two.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 "Rafael J. Wysocki" <rafael@...nel.org>, Danilo Krummrich <dakr@...nel.org>,
 Petr Mladek <pmladek@...e.com>, Steven Rostedt <rostedt@...dmis.org>,
 John Ogness <john.ogness@...utronix.de>,
 Sergey Senozhatsky <senozhatsky@...omium.org>,
 Ulf Hansson <ulf.hansson@...aro.org>, Thomas Gleixner <tglx@...utronix.de>,
 Andrey Ryabinin <ryabinin.a.a@...il.com>,
 Alexander Potapenko <glider@...gle.com>,
 Andrey Konovalov <andreyknvl@...il.com>, Dmitry Vyukov <dvyukov@...gle.com>,
 Vincenzo Frascino <vincenzo.frascino@....com>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Luis Chamberlain <mcgrof@...nel.org>, Petr Pavlu <petr.pavlu@...e.com>,
 Sami Tolvanen <samitolvanen@...gle.com>, Daniel Gomez
 <da.gomez@...sung.com>, Kent Overstreet <kent.overstreet@...ux.dev>,
 Anna-Maria Behnsen <anna-maria@...utronix.de>,
 Frederic Weisbecker <frederic@...nel.org>,
 Alexander Viro <viro@...iv.linux.org.uk>,
 Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
 Uladzislau Rezki <urezki@...il.com>, Matthew Wilcox <willy@...radead.org>,
 Kuan-Ying Lee <kuan-ying.lee@...onical.com>,
 Ilya Leoshkevich <iii@...ux.ibm.com>, Etienne Buira <etienne.buira@...e.fr>,
 Antonio Quartulli <antonio@...delbit.com>, Illia Ostapyshyn
 <illia@...yn.com>, "open list:COMMON CLK FRAMEWORK"
 <linux-clk@...r.kernel.org>,
 "open list:PER-CPU MEMORY ALLOCATOR" <linux-mm@...ck.org>,
 "open list:GENERIC PM DOMAINS" <linux-pm@...r.kernel.org>,
 "open list:KASAN" <kasan-dev@...glegroups.com>,
 "open list:MAPLE TREE" <maple-tree@...ts.infradead.org>,
 "open list:MODULE SUPPORT" <linux-modules@...r.kernel.org>,
 "open list:PROC FILESYSTEM" <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH 00/16] MAINTAINERS: Include GDB scripts under their
 relevant subsystems

On 26.06.25 18:17, Liam R. Howlett wrote:
> * Florian Fainelli <florian.fainelli@...adcom.com> [250625 19:13]:
>> Linux has a number of very useful GDB scripts under scripts/gdb/linux/*
>> that provide OS awareness for debuggers and allows for debugging of a
>> variety of data structures (lists, timers, radix tree, mapletree, etc.)
>> as well as subsystems (clocks, devices, classes, busses, etc.).
>>
>> These scripts are typically maintained in isolation from the subsystem
>> that they parse the data structures and symbols of, which can lead to
>> people playing catch up with fixing bugs or updating the script to work
>> with updates made to the internal APIs/objects etc. Here are some
>> recents examples:
>>
>> https://lore.kernel.org/all/20250601055027.3661480-1-tony.ambardar@gmail.com/
>> https://lore.kernel.org/all/20250619225105.320729-1-florian.fainelli@broadcom.com/
>> https://lore.kernel.org/all/20250625021020.1056930-1-florian.fainelli@broadcom.com/
>>
>> This patch series is intentionally split such that each subsystem
>> maintainer can decide whether to accept the extra
>> review/maintenance/guidance that can be offered when GDB scripts are
>> being updated or added.
> 
> I don't see why you think it was okay to propose this in the way you
> have gone about it.  Looking at the mailing list, you've been around for
> a while.
> 
> The file you are telling me about seems to be extremely new and I needed
> to pull akpm/mm-new to discover where it came from.. because you never
> Cc'ed me on the file you are asking me to own.
> 
> I'm actually apposed to the filename you used for the script you want me
> to own.
> 
> I consider myself a low-volume email maintainer and I get enough useless
> emails about apparent trivial fixes that end up causing significant
> damage if they are not dealt with.  So I take care not to sign up for
> more time erosion from meaningful forward progress on tasks I hope to
> have high impact.  I suspect you know that, but I don't know you so I
> don't want to assume.
> 
> Is there anything else you might want to share to entice me to maintain
> this file?  Perhaps there's a documentation pointer that shows how
> useful it is and why I should use it?
> 
> Right now, I have no idea what that file does or how to even check if
> that file works today, so I cannot sign on to maintain it.
> 
> If you want to depend on APIs, this should probably be generated in a
> way that enables updates.  And if that's the case, then why even have a
> file at all and just generate it when needed?  Or, at least, half
> generated and finished by hand?
> 
> Maybe this is the case but scripts/gdb doesn't have any documentation in
> there, there's no Documentation/scripts or Documentation/gdb either.
> 
> Can you please include more details on the uses of these files?  Failing
> that, perhaps you could point to any documentation?

FWIW, I once wrote
Documentation/process/debugging/gdb-kernel-debugging.rst. Hope it didn't
age too much.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Powered by blists - more mailing lists