On 6/27/25 00:55, Jan Kara wrote:
On Thu 26-06-25 09:39:36, Florian Fainelli wrote:
On 6/26/25 09:17, Liam R. Howlett wrote:
* Florian Fainelli <florian.faine...@broadcom.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.ambar...@gmail.com/
https://lore.kernel.org/all/20250619225105.320729-1-florian.faine...@broadcom.com/
https://lore.kernel.org/all/20250625021020.1056930-1-florian.faine...@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.
This should probably have been posted as RFC rather than PATCH, but as I
indicate in the cover letter this is broken down to allow maintainers like
yourself to accept/reject
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.
Yes, that file is very new indeed, and my bad for not copying you on it.
I was not planning on burning an entire day worth of work to transition the
GDB scripts dumping the interrupt tree away from a radix tree to a maple
tree. All of which happens with the author of that conversion having
absolutely no idea that broke anything in the tree because very few people
know about the Python GDB scripts that Linux has. It is not pleasant to be
playing catch when it would have take maybe an extra couple hours for
someone intimately familiar with the maple tree to come up with a suitable
implementation replacement for mtree_load().
So having done it felt like there is a maintenance void that needs to be
filled, hence this patch set.
I can see that it takes a lot of time to do a major update of a gdb
debugging script after some refactoring like this. OTOH mandating some gdb
scripts update is adding non-trivial amount of work to changes that are
already hard enough to do as is.
This really should have been posted as RFC, because I can see how
posting this as PATCH would be seen as coercing maintainers into taking
those GDB scripts under their umbrella.
And the obvious question is what is the
value? I've personally never used these gdb scripts and never felt a strong
need for something like that. People have various debugging aids (like BPF
scripts, gdb scripts, there's crash tool and drgn, and many more) lying
around.
Those are valuable tools in the tool box, but GDB scripts can work when
your only debug tool accessible is JTAG for instance, I appreciate this
is typically miles away from what most of the kernel community does, but
this is quite typical and common in embedded systems. When you operate
in that environment, having a decent amount of debugger awareness of
what is being debugged is immensely valuable in saving time.
I'm personally of an opinion that it is not a responsibility of
the person doing refactoring to make life easier for them or even fixing
them and I don't think that the fact that some debug aid is under
scripts/gdb/ directory is making it more special.
That is really the question that I am trying to get answered with this
patch series. IMHO as a subsystem maintainer it is not fair to be
completely oblivious to scripts that live in the source tree, even if
you are not aware of those.
> So at least as far as I'm> concerned (VFS, fsnotify and other
filesystem related stuff) I don't plan
on requiring updates to gdb scripts from people doing changes or otherwise
actively maintain them.
vfs.py script is beyond trivial, the largest and most complicated IMHO
is mapletree.py which had to be recently developed to continue to
support parsing the interrupt descriptor tree in the kernel, I can
maintain that one now that I know a lot more than I ever wished I knew
about maple trees. So really the burden is not as big as it may seem but
it's fair not to be taking on more work as a maintainer, I get that.
Thanks for your feedback!
--
Florian
