Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5;
Date:   Wed, 29 Nov 2023 15:06:29 -0800
From:   Andrew Morton <akpm@linux-foundation.org>
To:     Florian Fainelli <f.fainelli@gmail.com>
Cc:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Jan Kiszka <jan.kiszka@siemens.com>,
        Kieran Bingham <kbingham@kernel.org>,
        Shanker Donthineni <sdonthineni@nvidia.com>,
        Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@collabora.com>
Subject: Re: No care given to GDB scripts..
Message-Id: <20231129150629.0a82efbfc1494972e4e4f8cb@linux-foundation.org>
In-Reply-To: <cfc3aa17-0f1b-4ffc-b848-33baa51b1196@gmail.com>
References: <cfc3aa17-0f1b-4ffc-b848-33baa51b1196@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Wed, 29 Nov 2023 14:48:02 -0800 Florian Fainelli <f.fainelli@gmail.com> wrote:

> Hello,
> 
> It is quite clear that there are zero cares being given to making sure 
> that GDB scripts continue to work after making changes to core kernel 
> code, and why would you, because you probably did not know those 
> existed, but they do and they are used, and useful.
> 
> A recent example that was fixed by Kuan-Ying is this:
> 
> and now of course, "lx-interupts" also stopped working altogether after 
> this change:
> 
> https://lore.kernel.org/r/20230519134902.1495562-4-sdonthineni@nvidia.com
> 
> and who knows what else I could not test that is also broken.
> 
> We really need to find a better way to stop breaking GDB scripts, they 
> break way too often to be even remotely usable, and this is really sad.
> 
> It is also quite clear that we do not have enough continuous integration 
> and regression testing to ensure those breakages are caught ahead of time...
> 

This isn't terribly surprising - the gdb scripts are a pretty remote
corner and are peculiarly sensitive to getting damaged by routine
kernel development.

Is there any way of scripting the scripts so we can have some sort of
automated testing down under tools/testing/selftests/?