mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Dave Hansen <dave.hansen@intel.com>
Cc: linux-kernel@vger.kernel.org,
	"Ahmed S . Darwish" <darwi@linutronix.de>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ard Biesheuvel <ardb@kernel.org>, Arnd Bergmann <arnd@kernel.org>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H . Peter Anvin" <hpa@zytor.com>,
	John Ogness <john.ogness@linutronix.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH -v2 0/15] x86: Remove support for TSC-less and CX8-less CPUs
Date: Thu, 15 May 2025 16:43:20 +0200	[thread overview]
Message-ID: <aCX9iN5BxitdozwC@gmail.com> (raw)
In-Reply-To: <ae2478d9-640f-4c42-86ec-31cbe5955a59@intel.com>


* Dave Hansen <dave.hansen@intel.com> wrote:

> On 5/15/25 01:56, Ingo Molnar wrote:
> >  80 files changed, 47 insertions(+), 14117 deletions(-)
> 
> Thanks for doing this, Ingo. A lot of this code was sitting off on 
> the side and not causing _too_ many problems. But that was (I think) 
> mostly because it was being so lightly used.
> 
> I've been using Linux since the late 90's. The oldest systems I ever 
> ran it on were i586's and they were old at the time.
> 
> I suspect this is going to throw a couple more compile issues at us 
> to fix, that's par for the course on something like this. Ideally, 
> we'd wait for v6.16-rc1 for applying something of this magnitude. 
> What were your plans on when to apply it?

Yeah, so the good news is that the bots have been build-testing this 
series for a few weeks, and besides an UML build issue that I fixed 
there were very few problems. (knock on wood)

And since Linus asked for this and semi-acked it, I might try sending 
this in this merge window, if it's quiet enough from the x86 tree 
perspective. The diffstat is large, but as you too alluded to, it's 
99.9% obsolete code that got very little testing in practice, so I 
don't think there's an elevated risk of regressions. But let's see how 
the v6.16 merge window goes?

> In any case:
> 
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>

Thanks!

	Ingo

      reply	other threads:[~2025-05-15 14:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-15  8:56 Ingo Molnar
2025-05-15  8:56 ` [PATCH 01/15] x86/cpu: Remove M486/M486SX/ELAN support Ingo Molnar
2025-05-15  8:56 ` [PATCH 02/15] x86/cpu: Remove CONFIG_MWINCHIP3D/MWINCHIPC6 Ingo Molnar
2025-05-15  8:56 ` [PATCH 03/15] x86/cpu: Remove CPU_SUP_UMC_32 support Ingo Molnar
2025-05-15  8:56 ` [PATCH 04/15] x86/cpu: Remove TSC-less CONFIG_M586 support Ingo Molnar
2025-05-15  8:56 ` [PATCH 05/15] x86/cpu, x86/platform, watchdog: Remove CONFIG_X86_RDC321X support Ingo Molnar
2025-05-15  8:56 ` [PATCH 06/15] x86/cpu: Remove the CONFIG_X86_INVD_BUG quirk Ingo Molnar
2025-05-15  8:56 ` [PATCH 07/15] x86/cpu, cpufreq: Remove AMD ELAN support Ingo Molnar
2025-05-15  8:56 ` [PATCH 08/15] x86/fpu: Remove MATH_EMULATION and related glue code Ingo Molnar
2025-05-15  8:56 ` [PATCH 09/15] x86/fpu: Remove the 'no387' boot option Ingo Molnar
2025-05-15  8:57 ` [PATCH 10/15] x86/fpu: Remove the math-emu/ FPU emulation library Ingo Molnar
2025-05-15  8:57 ` [PATCH 11/15] x86/cpu: Make CONFIG_X86_TSC unconditional Ingo Molnar
2025-05-15  8:57 ` [PATCH 12/15] x86: Remove !CONFIG_X86_TSC code Ingo Molnar
2025-05-15  8:57 ` [PATCH 13/15] x86/cpu: Make CONFIG_X86_CX8 unconditional Ingo Molnar
2025-05-15  8:57 ` [PATCH 14/15] x86/atomics: Remove !CONFIG_X86_CX8 methods Ingo Molnar
2025-05-15 13:00   ` [PATCH -v3 " Ingo Molnar
2025-05-15  8:57 ` [PATCH 15/15] x86/percpu: " Ingo Molnar
2025-05-29 12:45   ` Uros Bizjak
2025-05-15 14:20 ` [PATCH -v2 0/15] x86: Remove support for TSC-less and CX8-less CPUs Dave Hansen
2025-05-15 14:43   ` Ingo Molnar [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aCX9iN5BxitdozwC@gmail.com \
    --to=mingo@kernel.org \
    --cc=andrew.cooper3@citrix.com \
    --cc=ardb@kernel.org \
    --cc=arnd@kernel.org \
    --cc=bp@alien8.de \
    --cc=darwi@linutronix.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome