[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wi_KMO_rJ6OCr8mAWBRg-irziM=T9wxGC+J1VVoQb39gw@mail.gmail.com>
Date: Sun, 23 Jun 2024 13:48:52 -0400
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Uros Bizjak <ubizjak@...il.com>
Cc: kernel test robot <lkp@...el.com>, oe-kbuild-all@...ts.linux.dev,
linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
Borislav Petkov <bp@...en8.de>, Peter Zijlstra <peterz@...radead.org>
Subject: Re: arch/x86/include/asm/cmpxchg_32.h:149:9: error: inline assembly
requires more registers than available
On Sun, 23 Jun 2024 at 13:43, Uros Bizjak <ubizjak@...il.com> wrote:
>
> I disagree with the above.
Your disagreement just doesn't matter.
We don't introduce regressions and then blame others.
There's a very clear rule in kernel development: things that break
other things ARE NOT FIXES.
EVER.
They get reverted, or the thing they broke gets fixed.
This is not debatable, or something you can "disagree"' with. This is
how we work, and if you disagree with that, you had better get out of
kernel development.
> As said in my previous message, if the compiler can't handle
> __try_cmpxchg implementation, the most straightforward and reliable
> solution is to implement atomic64_{and,or,xor} as outline functions,
You also seemed to say that nobody was doing it.
Which means "revert". Because that I can do trivially.
Now, from having looked a bit at this, I can point you to the
differences introduced by having to have the emulation fallback.
And I would personally be ok with leaving Pentium etc entirely behind,
and getting rid of said fallback, but that's an entirely separate
thing that will require much more discussion.
Some people still wanted to support old 486 clones not that long ago.
Linus
Powered by blists - more mailing lists