Received-SPF: pass (google.com: domain of linux-kernel+bounces-199061-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <34c519412fbaca9d5f08990ff96c4c928869bf84.camel@physik.fu-berlin.de>
Subject: Re: [PATCH 00/14] alpha: cleanups for 6.10
From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>, Linus Torvalds
	 <torvalds@linux-foundation.org>
Cc: "Paul E. McKenney" <paulmck@kernel.org>, Arnd Bergmann
 <arnd@kernel.org>,  linux-alpha@vger.kernel.org, Arnd Bergmann
 <arnd@arndb.de>, Richard Henderson <richard.henderson@linaro.org>, Ivan
 Kokshaysky <ink@jurassic.park.msu.ru>,  Matt Turner <mattst88@gmail.com>,
 Alexander Viro <viro@zeniv.linux.org.uk>, Marc Zyngier <maz@kernel.org>, 
 linux-kernel@vger.kernel.org, Michael Cree <mcree@orcon.net.nz>, Frank
 Scheiner <frank.scheiner@web.de>
Date: Mon, 03 Jun 2024 13:36:40 +0200
In-Reply-To: <alpine.DEB.2.21.2405310457060.23854@angie.orcam.me.uk>
References: <20240503081125.67990-1-arnd@kernel.org>
	 <272a909522f2790a30b9a8be73ab7145bf06d486.camel@physik.fu-berlin.de>
	 <alpine.DEB.2.21.2405280041550.23854@angie.orcam.me.uk>
	 <aa397ad5-a08a-48a1-a9c0-75cfd5f6a3a5@paulmck-laptop>
	 <alpine.DEB.2.21.2405291432450.23854@angie.orcam.me.uk>
	 <CAHk-=wi7WfDSfunEXmCqDnH+55gumjhDar-KO_=66ziuP33piw@mail.gmail.com>
	 <alpine.DEB.2.21.2405302115130.23854@angie.orcam.me.uk>
	 <CAHk-=whiH6g+T7+YWSYgAhJ9HsJ2bUUDJfLLo_Yhbi8CVgkHDg@mail.gmail.com>
	 <alpine.DEB.2.21.2405310457060.23854@angie.orcam.me.uk>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.52.1 
Precedence: bulk
MIME-Version: 1.0

Hi Maciej,

On Mon, 2024-06-03 at 12:09 +0100, Maciej W. Rozycki wrote:
>  Anyway, back to my point.  A feasible solution non-intrusive for Linux=
=20
> and low-overhead for GCC has been found.  I can expedite implementation=
=20
> and I'll see if I can regression-test it too, but I may have to rely on=
=20
> other people to complete it after all, as I haven't been prepared for thi=
s=20
> effort in the light of certain issues I have recently suffered from in my=
=20
> lab.

That's really great to hear! Please let me know if you have something to te=
st,
I would love to help with this effort.

>  Is that going to be enough to bring the platform bits back?

That would be awesome. Would love to be able to keep running a current kern=
el
on my AlphaStation 233 which is pre-EV56.

>  FAOD, with all the hacks so eagerly being removed now happily left in th=
e=20
> dust bin where they belong, and which I wholeheartedly agree with: we=20
> shouldn't be suffering from design mistakes of systems that are no longer=
=20
> relevant, but I fail to see the reason why we should disallow their use=
=20
> where the burden is confined or plain elsewhere.

Agreed.

>  For example we continue supporting old UP MIPS platforms that predate=
=20
> LL/SC, by just trapping and emulating these instructions.  Surely it suck=
s=20
> performance-wise and it's possibly hundreds of cycles too, but it works=
=20
> and the burden is confined to the exception handler, so not a big deal.

Fully agreed.

Adrian

--=20
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913