Message-ID: <fynmrmsglw4liexcb37ykutf724lh7zbibilcjpysbmvgtkmes@mtjrfkve4av7>
Date: Thu, 26 Jun 2025 12:17:41 -0400
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: Florian Fainelli <florian.fainelli@...adcom.com>
Cc: linux-kernel@...r.kernel.org, Jan Kiszka <jan.kiszka@...mens.com>,
        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

* 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?

...

Regards,
Liam

Powered by blists - more mailing lists