[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e08c4462-7ecd-4c2a-bd08-c38ec148b5c8@loongson.cn>
Date: Fri, 5 Sep 2025 16:29:04 +0800
From: Ming Wang <wangming01@...ngson.cn>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: WangYuli <wangyuli@...ontech.com>, ardb@...nel.org,
chenhuacai@...nel.org, chenhuacai@...ngson.cn, kernel@...0n.name,
linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
loongarch@...ts.linux.dev, masahiroy@...nel.org, nathan@...nel.org,
ndesaulniers@...gle.com, nicolas@...sle.eu, sashal@...nel.org,
stable@...r.kernel.org
Subject: Re: [PATCH 6.1&6.6 0/3] kbuild: Avoid weak external linkage where
possible
Hi Greg,
On 9/5/25 15:09, Greg KH wrote:
> On Fri, Sep 05, 2025 at 02:49:44PM +0800, Ming Wang wrote:
>> Hi Greg, all,
>>
>> On 2/6/25 18:03, Greg KH wrote:
>>> On Thu, Feb 06, 2025 at 04:37:02PM +0800, WangYuli wrote:
>>>> Hi, Greg,
>>>>
>>>> It's rather unfortunate that currently, almost all Linux distributions
>>>> supporting LoongArch are using LTS kernels version v6.6 or older, such as
>>>> openEuler and deepin. [1][2]
>>>>
>>>> If this bugfix isn't merged into linux-stable, then every single distro
>>>> kernel team will have to waste time fixing the same darn bug over and
>>>> over, even though it's already fixed in later kernels.
>>>>
>>>> This would really make LTS look like it's failing to serve its intended
>>>> purpose. And I'm sure all of us do not want to see something so terrible
>>>> happen.
>>>
>>> LTS is here to ensure that the original release of these branches, keeps
>>> working for that branch. Adding support for newer toolchains sometimes
>>> happens, but is not a requirement or a normal thing to do as that really
>>> isn't a "regression", right?
>>>
>>> Most of the time, fixing things up for newer compilers is simple.
>>> Sometimes it is not simple. The "not simple" ones we usually just do
>>> not backport as that causes extra work for everyone over time.
>>>
>>> As for the distros like openEuler, and deepin, they are free to add
>>> these patches there, on top of their other non-LTS patches, right?
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>> I'm writing to follow up on this important discussion. I have carefully
>> read the entire thread, including your explanation of the LTS philosophy
>> regarding support for new toolchains. I understand and respect the
>> principle that LTS aims to maintain stability for the environment in
>> which it was released, and that adapting to future toolchains is
>> primarily a distributor's responsibility.
>>
>> However, I would like to respectfully ask for a reconsideration by
>> framing this issue from a slightly different perspective, based on the
>> excellent technical analysis provided by Xi Ruoyao and Ard Biesheuvel.
>
> <snip>
>
> i'm sorry, but for an email thread that happened 6+ months ago, it's a
> bit hard to try to remember anything involved in it.
>
> Heck, I can't remember an email thread from last week.
>
> Remember, some of us get 1000+ emails a day to deal with.
>
> If you feel a patch set should be applied to a stable tree, and it has
> been rejected in the past, feel free to resubmit it with all of the new
> information about why the previous rejection was wrong and why it really
> should be applied this time. Otherwise, there's really nothing I could
> possibly do here as the patches are long gone from everyone's review
> queues.
>
> Also, why aren't you just using 6.12.y now? :)
>
> thanks,
>
> greg k-h
Thank you for the quick reply.You've raised a very fair point about
moving to a newer kernel. Thanks again for your time and the guidance.
Best Regards,
Robin
Powered by blists - more mailing lists