In the x86 architecture we have various complicated hardware emulation
facilities on x86-32 to support ancient 32-bit CPUs that very very few
people are using with modern kernels. This compatibility glue is sometimes
even causing problems that people spend time to resolve, which time could
be spent on other things.

As Linus recently remarked:

 > I really get the feeling that it's time to leave i486 support behind.
 > There's zero real reason for anybody to waste one second of
 > development effort on this kind of issue.

This series increases minimum kernel support features to include TSC and
CX8 (CMPXCHG8B) hardware support, which removes 486 (and derivatives) support
and early-586 (and derivatives) support.

Doing this allows the removal of a fair amount of code:

 80 files changed, 38 insertions(+), 14104 deletions(-)

Much of which is the math-emu/ library - but even without math-emu,
the simplification is substantial:

 33 files changed, 38 insertions(+), 1081 deletions(-)

This series has 5 main parts:

1) Removal of the main CPU options and their dependencies in the Kconfig space:

     x86/cpu: Remove M486/M486SX/ELAN support
     x86/cpu: Remove CONFIG_MWINCHIP3D/MWINCHIPC6
     x86/cpu: Remove CPU_SUP_UMC_32 support
     x86/cpu: Remove TSC-less CONFIG_M586 support

2) Remove platform support for chips that weren't carried forward
   after these CPUs:

     x86/cpu, x86/platform, watchdog: Remove CONFIG_X86_RDC321X support
     x86/cpu: Remove the CONFIG_X86_INVD_BUG quirk
     x86/cpu, cpufreq: Remove AMD ELAN support

3) Remove math-emu/ support:

     x86/fpu: Remove MATH_EMULATION and related glue code
     x86/fpu: Remove the 'no387' boot option
     x86/fpu: Remove the math-emu/ FPU emulation library

4) Make CONFIG_X86_TSC unconditional and simplify the build-time TSC variances:

     x86/cpu: Make CONFIG_X86_TSC unconditional
     x86: Remove !CONFIG_X86_TSC code

   Note that runtime TSC disabling is still kept in its various forms.

   Also note that I kept CONFIG_X86_TSC itself, which is a proxy for
   a few drivers for 'sane x86', and which might be used in changes
   still in-flight. There's very little cost to keep this Kconfig option
   going forward, even though it's always-enabled.

5) Make CONFIG_X86_CX8 unconditional and remove build-time complications:

     x86/cpu: Make CONFIG_X86_CX8 unconditional
     x86/percpu: Remove !CONFIG_X86_CX8 methods
     x86/atomics: Remove !CONFIG_X86_CX8 methods

   Note that CONFIG_X86_CX8 is still kept, but not used by anything
   anymore. We can probably remove it entirely and there's no expectation
   of pending/outside code having dependency on this.

Note that there's still some stray references to removed platforms in
the main x86 Kconfig and Kconfig.x86, and the entire vector of CPU
options is probably overly complicated and should probably be replaced
with a single option - I'll clean that all up once there's rough
agreement about the scope of this RFC series.

The tree can also be found in my tree:

   git://git.kernel.org/pub/scm/linux/kernel/git/mingo/tip.git WIP.x86/cpu

Lightly tested.

Thanks,

    Ingo

================>
Ingo Molnar (15):
  x86/cpu: Remove M486/M486SX/ELAN support
  x86/cpu: Remove CONFIG_MWINCHIP3D/MWINCHIPC6
  x86/cpu: Remove CPU_SUP_UMC_32 support
  x86/cpu: Remove TSC-less CONFIG_M586 support
  x86/cpu, x86/platform, watchdog: Remove CONFIG_X86_RDC321X support
  x86/cpu: Remove the CONFIG_X86_INVD_BUG quirk
  x86/cpu, cpufreq: Remove AMD ELAN support
  x86/fpu: Remove MATH_EMULATION and related glue code
  x86/fpu: Remove the 'no387' boot option
  x86/fpu: Remove the math-emu/ FPU emulation library
  x86/cpu: Make CONFIG_X86_TSC unconditional
  x86: Remove !CONFIG_X86_TSC code
  x86/cpu: Make CONFIG_X86_CX8 unconditional
  x86/percpu: Remove !CONFIG_X86_CX8 methods
  x86/atomics: Remove !CONFIG_X86_CX8 methods

 Documentation/admin-guide/kernel-parameters.txt |    4 -
 arch/x86/Kconfig                                |   71 +-
 arch/x86/Kconfig.cpu                            |   95 +-
 arch/x86/Kconfig.cpufeatures                    |    2 -
 arch/x86/Makefile                               |    1 -
 arch/x86/Makefile_32.cpu                        |    8 -
 arch/x86/include/asm/asm-prototypes.h           |    4 -
 arch/x86/include/asm/atomic64_32.h              |   17 +-
 arch/x86/include/asm/cmpxchg_32.h               |   86 +-
 arch/x86/include/asm/fpu/api.h                  |    6 -
 arch/x86/include/asm/percpu.h                   |    6 +-
 arch/x86/include/asm/timex.h                    |    3 +-
 arch/x86/include/asm/trace_clock.h              |    8 -
 arch/x86/include/asm/tsc.h                      |   13 +-
 arch/x86/include/asm/vermagic.h                 |   12 -
 arch/x86/kernel/Makefile                        |    4 +-
 arch/x86/kernel/cpu/common.c                    |    7 -
 arch/x86/kernel/cpu/umc.c                       |   26 -
 arch/x86/kernel/fpu/core.c                      |    5 -
 arch/x86/kernel/fpu/init.c                      |    9 +-
 arch/x86/kernel/i8253.c                         |    2 +-
 arch/x86/kernel/traps.c                         |   21 -
 arch/x86/kernel/tsc.c                           |   13 -
 arch/x86/lib/Makefile                           |    4 -
 arch/x86/lib/atomic64_386_32.S                  |  195 ---
 arch/x86/lib/cmpxchg8b_emu.S                    |   97 --
 arch/x86/math-emu/Makefile                      |   30 -
 arch/x86/math-emu/README                        |  427 ------
 arch/x86/math-emu/control_w.h                   |   46 -
 arch/x86/math-emu/div_Xsig.S                    |  367 -----
 arch/x86/math-emu/div_small.S                   |   48 -
 arch/x86/math-emu/errors.c                      |  686 ----------
 arch/x86/math-emu/exception.h                   |   51 -
 arch/x86/math-emu/fpu_arith.c                   |  153 ---
 arch/x86/math-emu/fpu_asm.h                     |   32 -
 arch/x86/math-emu/fpu_aux.c                     |  267 ----
 arch/x86/math-emu/fpu_emu.h                     |  218 ---
 arch/x86/math-emu/fpu_entry.c                   |  718 ----------
 arch/x86/math-emu/fpu_etc.c                     |  136 --
 arch/x86/math-emu/fpu_proto.h                   |  157 ---
 arch/x86/math-emu/fpu_system.h                  |  130 --
 arch/x86/math-emu/fpu_tags.c                    |  116 --
 arch/x86/math-emu/fpu_trig.c                    | 1649 -----------------------
 arch/x86/math-emu/get_address.c                 |  401 ------
 arch/x86/math-emu/load_store.c                  |  322 -----
 arch/x86/math-emu/mul_Xsig.S                    |  179 ---
 arch/x86/math-emu/poly.h                        |  115 --
 arch/x86/math-emu/poly_2xm1.c                   |  146 --
 arch/x86/math-emu/poly_atan.c                   |  209 ---
 arch/x86/math-emu/poly_l2.c                     |  245 ----
 arch/x86/math-emu/poly_sin.c                    |  379 ------
 arch/x86/math-emu/poly_tan.c                    |  213 ---
 arch/x86/math-emu/polynom_Xsig.S                |  137 --
 arch/x86/math-emu/reg_add_sub.c                 |  334 -----
 arch/x86/math-emu/reg_compare.c                 |  479 -------
 arch/x86/math-emu/reg_constant.c                |  123 --
 arch/x86/math-emu/reg_constant.h                |   26 -
 arch/x86/math-emu/reg_convert.c                 |   47 -
 arch/x86/math-emu/reg_divide.c                  |  183 ---
 arch/x86/math-emu/reg_ld_str.c                  | 1220 -----------------
 arch/x86/math-emu/reg_mul.c                     |  116 --
 arch/x86/math-emu/reg_norm.S                    |  150 ---
 arch/x86/math-emu/reg_round.S                   |  711 ----------
 arch/x86/math-emu/reg_u_add.S                   |  169 ---
 arch/x86/math-emu/reg_u_div.S                   |  474 -------
 arch/x86/math-emu/reg_u_mul.S                   |  150 ---
 arch/x86/math-emu/reg_u_sub.S                   |  274 ----
 arch/x86/math-emu/round_Xsig.S                  |  142 --
 arch/x86/math-emu/shr_Xsig.S                    |   89 --
 arch/x86/math-emu/status_w.h                    |   68 -
 arch/x86/math-emu/version.h                     |   12 -
 arch/x86/math-emu/wm_shrx.S                     |  207 ---
 arch/x86/math-emu/wm_sqrt.S                     |  472 -------
 arch/x86/xen/Kconfig                            |    2 +-
 drivers/cpufreq/Kconfig.x86                     |   26 -
 drivers/cpufreq/Makefile                        |    2 -
 drivers/cpufreq/elanfreq.c                      |  227 ----
 drivers/cpufreq/sc520_freq.c                    |  137 --
 drivers/watchdog/Kconfig                        |    2 +-
 lib/atomic64_test.c                             |    4 +-
 80 files changed, 38 insertions(+), 14104 deletions(-)
 delete mode 100644 arch/x86/kernel/cpu/umc.c
 delete mode 100644 arch/x86/lib/atomic64_386_32.S
 delete mode 100644 arch/x86/lib/cmpxchg8b_emu.S
 delete mode 100644 arch/x86/math-emu/Makefile
 delete mode 100644 arch/x86/math-emu/README
 delete mode 100644 arch/x86/math-emu/control_w.h
 delete mode 100644 arch/x86/math-emu/div_Xsig.S
 delete mode 100644 arch/x86/math-emu/div_small.S
 delete mode 100644 arch/x86/math-emu/errors.c
 delete mode 100644 arch/x86/math-emu/exception.h
 delete mode 100644 arch/x86/math-emu/fpu_arith.c
 delete mode 100644 arch/x86/math-emu/fpu_asm.h
 delete mode 100644 arch/x86/math-emu/fpu_aux.c
 delete mode 100644 arch/x86/math-emu/fpu_emu.h
 delete mode 100644 arch/x86/math-emu/fpu_entry.c
 delete mode 100644 arch/x86/math-emu/fpu_etc.c
 delete mode 100644 arch/x86/math-emu/fpu_proto.h
 delete mode 100644 arch/x86/math-emu/fpu_system.h
 delete mode 100644 arch/x86/math-emu/fpu_tags.c
 delete mode 100644 arch/x86/math-emu/fpu_trig.c
 delete mode 100644 arch/x86/math-emu/get_address.c
 delete mode 100644 arch/x86/math-emu/load_store.c
 delete mode 100644 arch/x86/math-emu/mul_Xsig.S
 delete mode 100644 arch/x86/math-emu/poly.h
 delete mode 100644 arch/x86/math-emu/poly_2xm1.c
 delete mode 100644 arch/x86/math-emu/poly_atan.c
 delete mode 100644 arch/x86/math-emu/poly_l2.c
 delete mode 100644 arch/x86/math-emu/poly_sin.c
 delete mode 100644 arch/x86/math-emu/poly_tan.c
 delete mode 100644 arch/x86/math-emu/polynom_Xsig.S
 delete mode 100644 arch/x86/math-emu/reg_add_sub.c
 delete mode 100644 arch/x86/math-emu/reg_compare.c
 delete mode 100644 arch/x86/math-emu/reg_constant.c
 delete mode 100644 arch/x86/math-emu/reg_constant.h
 delete mode 100644 arch/x86/math-emu/reg_convert.c
 delete mode 100644 arch/x86/math-emu/reg_divide.c
 delete mode 100644 arch/x86/math-emu/reg_ld_str.c
 delete mode 100644 arch/x86/math-emu/reg_mul.c
 delete mode 100644 arch/x86/math-emu/reg_norm.S
 delete mode 100644 arch/x86/math-emu/reg_round.S
 delete mode 100644 arch/x86/math-emu/reg_u_add.S
 delete mode 100644 arch/x86/math-emu/reg_u_div.S
 delete mode 100644 arch/x86/math-emu/reg_u_mul.S
 delete mode 100644 arch/x86/math-emu/reg_u_sub.S
 delete mode 100644 arch/x86/math-emu/round_Xsig.S
 delete mode 100644 arch/x86/math-emu/shr_Xsig.S
 delete mode 100644 arch/x86/math-emu/status_w.h
 delete mode 100644 arch/x86/math-emu/version.h
 delete mode 100644 arch/x86/math-emu/wm_shrx.S
 delete mode 100644 arch/x86/math-emu/wm_sqrt.S
 delete mode 100644 drivers/cpufreq/elanfreq.c
 delete mode 100644 drivers/cpufreq/sc520_freq.c

-- 
2.45.2

Hi!

> In the x86 architecture we have various complicated hardware emulation
> facilities on x86-32 to support ancient 32-bit CPUs that very very few
> people are using with modern kernels. This compatibility glue is sometimes
> even causing problems that people spend time to resolve, which time could
> be spent on other things.

We have open-source 486 cores, such as
https://github.com/MiSTer-devel/ao486_MiSTer . I'm not aware of
open-source 586 cores... so this is a bit sad.

Best regards,
									Pavel
-- 
I don't work for Nazis and criminals, and neither should you.
Boycott Putin, Trump, and Musk!

On Fri, Apr 25, 2025, at 10:41, Ingo Molnar wrote:
> In the x86 architecture we have various complicated hardware emulation
> facilities on x86-32 to support ancient 32-bit CPUs that very very few
> people are using with modern kernels. This compatibility glue is sometimes
> even causing problems that people spend time to resolve, which time could
> be spent on other things.
>
> As Linus recently remarked:
>
>  > I really get the feeling that it's time to leave i486 support behind.
>  > There's zero real reason for anybody to waste one second of
>  > development effort on this kind of issue.
>
> This series increases minimum kernel support features to include TSC and
> CX8 (CMPXCHG8B) hardware support, which removes 486 (and derivatives) support
> and early-586 (and derivatives) support.

Looks all good to me, thanks for including my earlier feedback.

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

On Fri, 25 Apr 2025, Ingo Molnar wrote:

>  > I really get the feeling that it's time to leave i486 support behind.
>  > There's zero real reason for anybody to waste one second of
>  > development effort on this kind of issue.
> 
> This series increases minimum kernel support features to include TSC and
> CX8 (CMPXCHG8B) hardware support, which removes 486 (and derivatives) support
> and early-586 (and derivatives) support.

 FWIW I'm not happy about that at the very least because this will prevent 
me from using my 486 box for EISA defxx driver maintenance.  What exactly 
is the problem with 486?

 I know the lack of TSC has security implications, but don't use the 
machine in a way for which it would be an issue and I don't expect anyone 
doing otherwise.  We have non-x86 platforms that lack a high-resolution 
timer and nobody's going to drop them.

 We also have platforms that lack atomics, let alone double-precision ones 
and they're fine too, so why is x86 different?

  Maciej

On Mon, 5 May 2025 at 01:53, Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>
>  We also have platforms that lack atomics, let alone double-precision ones
> and they're fine too, so why is x86 different?

So I don't know if you saw this thread:

   https://lore.kernel.org/all/202504211553.3ba9400-lkp@intel.com/

where I initially thought that it was the lack of TSC, but it looks
like it's the CMPXCHG8B code that ends up causing problems.

And the core issue boils down to "there's no point in wasting time on
even debugging this".

So basically, the support for i486 costs us more than it is worth.

             Linus

On Mon, 5 May 2025, Linus Torvalds wrote:

> >  We also have platforms that lack atomics, let alone double-precision ones
> > and they're fine too, so why is x86 different?
> 
> So I don't know if you saw this thread:
> 
>    https://lore.kernel.org/all/202504211553.3ba9400-lkp@intel.com/
> 
> where I initially thought that it was the lack of TSC, but it looks
> like it's the CMPXCHG8B code that ends up causing problems.

 I did glance over (in my effort to process outstanding 40k mailing list 
messages in two days), but haven't spotted CMPXCHG8B being the culprit; 
thanks for the pointer.

> And the core issue boils down to "there's no point in wasting time on
> even debugging this".

 Sadly I tend to agree, being unable, owing to time constraints, to commit 
myself to doing such debugging (NB glibc verification crashes i386 Linux 
reliably on Pentium MMX, apparently due to FP context corruption, and I 
need to prioritise debugging that, once I've figured out which actual test 
case triggers it, as due to the oddity of the glibc test system it's quite 
tough getting the logs matched between the host and the target system).

> So basically, the support for i486 costs us more than it is worth.

 So the cost has to be reduced and just as I proposed on the previous 
iteration last year this can be solved quite easily without sacrificing 
i486 support by adding #UD handler for CMPXCHG8B, just as we did for 
analogous stuff with some RISC platforms years if not decades ago.

 I was told in said discussion that decoding x86 address modes was not as
easy as with RISC modes (thank you, Captain Obvious!), but still that 
boils down to indexing into registers by ModR/M and SIB bit-fields, with a 
couple of corner cases, which ought to be less than a screenful of code.  
If objdump(1) can do it, so can we.

 No i486 has ever run Linux SMP.  Back in the day I tried hard to chase by 
the spec a single i486 system built around the APIC and Intel MP Spec and 
could not find any.  Compaq had some proprietary stuff (Corollary bus?) we 
never had support for.  And we discarded support for the discrete i82489DX 
APIC years ago anyway that some Pentium systems used too for the original 
P5 microarchitecture or to go beyond dual.  So said emulation would have 
to handle the UP case only, which ought to be straightforward and well 
contained.

 Thoughts?

  Maciej

On May 6, 2025 6:53:34 AM PDT, "Maciej W. Rozycki" <macro@orcam.me.uk> wrote:
>On Mon, 5 May 2025, Linus Torvalds wrote:
>
>> >  We also have platforms that lack atomics, let alone double-precision ones
>> > and they're fine too, so why is x86 different?
>> 
>> So I don't know if you saw this thread:
>> 
>>    https://lore.kernel.org/all/202504211553.3ba9400-lkp@intel.com/
>> 
>> where I initially thought that it was the lack of TSC, but it looks
>> like it's the CMPXCHG8B code that ends up causing problems.
>
> I did glance over (in my effort to process outstanding 40k mailing list 
>messages in two days), but haven't spotted CMPXCHG8B being the culprit; 
>thanks for the pointer.
>
>> And the core issue boils down to "there's no point in wasting time on
>> even debugging this".
>
> Sadly I tend to agree, being unable, owing to time constraints, to commit 
>myself to doing such debugging (NB glibc verification crashes i386 Linux 
>reliably on Pentium MMX, apparently due to FP context corruption, and I 
>need to prioritise debugging that, once I've figured out which actual test 
>case triggers it, as due to the oddity of the glibc test system it's quite 
>tough getting the logs matched between the host and the target system).
>
>> So basically, the support for i486 costs us more than it is worth.
>
> So the cost has to be reduced and just as I proposed on the previous 
>iteration last year this can be solved quite easily without sacrificing 
>i486 support by adding #UD handler for CMPXCHG8B, just as we did for 
>analogous stuff with some RISC platforms years if not decades ago.
>
> I was told in said discussion that decoding x86 address modes was not as
>easy as with RISC modes (thank you, Captain Obvious!), but still that 
>boils down to indexing into registers by ModR/M and SIB bit-fields, with a 
>couple of corner cases, which ought to be less than a screenful of code.  
>If objdump(1) can do it, so can we.
>
> No i486 has ever run Linux SMP.  Back in the day I tried hard to chase by 
>the spec a single i486 system built around the APIC and Intel MP Spec and 
>could not find any.  Compaq had some proprietary stuff (Corollary bus?) we 
>never had support for.  And we discarded support for the discrete i82489DX 
>APIC years ago anyway that some Pentium systems used too for the original 
>P5 microarchitecture or to go beyond dual.  So said emulation would have 
>to handle the UP case only, which ought to be straightforward and well 
>contained.
>
> Thoughts?
>
>  Maciej

However, building a #UD instruction emulator is a project in itself that someone would have to take on. It isn't inherently simpler – quite the opposite – than the alternatives calling to a stub function than we have now.

We have the tools to do it; there is now a full x86 instruction decoder in the kernel that one could use to do this, but...

a. Someone would have to take it on;
b. It will need continuous testing;
c. That someone would *also* have to go through the additional effort of keeping the mainline code clean for the maintainers of the modern hardware.

And at some point we will be at a point where we were with i386 that the only users are occasional testers.

With regards to EISA, you still haven't clarified if there is a true use case or if this is a museum/nostalgia project. There isn't anything *wrong* with museum projects, not at all (I recently got to play SPACEWAR! on a real PDP-1; it was amazing) but imposing a maintenance burden on the mainline developers of one of the most heavily used architecture on the planet is not practical.

If someone really wanted to, they could maybe fork off, say, arch/i486 and maintain the a version of the kernel limited to these old machines, but it would require someone being willing to do the work. 

On Tue, 6 May 2025, H. Peter Anvin wrote:

> > No i486 has ever run Linux SMP.  Back in the day I tried hard to chase by 
> >the spec a single i486 system built around the APIC and Intel MP Spec and 
> >could not find any.  Compaq had some proprietary stuff (Corollary bus?) we 
> >never had support for.  And we discarded support for the discrete i82489DX 
> >APIC years ago anyway that some Pentium systems used too for the original 
> >P5 microarchitecture or to go beyond dual.  So said emulation would have 
> >to handle the UP case only, which ought to be straightforward and well 
> >contained.
> 
> However, building a #UD instruction emulator is a project in itself that 
> someone would have to take on. It isn't inherently simpler – quite the 
> opposite – than the alternatives calling to a stub function than we have 
> now.

 Perhaps my RISC background makes me view instruction emulation as simpler 
than patching code.  It has been common throughout computing history too.  
In any case it would contain all the handling in a single function called 
from the generic #UD exception handler, something that could be `if 
(IS_ENABLED(CONFIG_M486))' and therefore completely ignored for all the 
newer platforms, and leaving the rest of the kernel code exactly the same 
as we now have for CMPXCHG8B platforms.

 My x86-fu is a bit rusty and surely I'm not familiar with all the recent 
features, however I retain my 20+ years of past experience, most recently 
with interfacing Atom systems via a JTAG probe to GDB over the remote 
serial protocol (which did include writing instruction emulation in the 
debug stub, specifically for MOV to/from debug registers or you wouldn't 
be able to run e.g. BIOS initialisation with the debugger attached due to 
the general-detect fault), and the i486/Pentium stuff is contemporary to 
my experience, so writing such an emulation handler shouldn't be a big 
deal to me.

 Note that we'll only have to emulate it for the kernel itself, so the 
emulation won't have to handle all the obscure corner cases, such as 
16-bit address modes, odd segment prefixes, or VM86 mode.

> We have the tools to do it; there is now a full x86 instruction decoder 
> in the kernel that one could use to do this, but...
> 
> a. Someone would have to take it on;
> b. It will need continuous testing;
> c. That someone would *also* have to go through the additional effort of 
>    keeping the mainline code clean for the maintainers of the modern 
>    hardware.

 I'd expect instruction emulation code to be zero-maintenance effort.  We 
have had such bits in the MIPS platform and they haven't been touched in 
decades.  It's not like machine instruction interpretation is ever going 
to change.  And none of the x86 maintainters will have to care whether it 
actually works, as nobody will see any adverse effect *unless* they build 
an i486 kernel *and* actually run it on an i486 both at a time.  Anything 
newer just won't ever trigger it.

> And at some point we will be at a point where we were with i386 that the 
> only users are occasional testers.

 I agree that the lack of the WP bit with the original i386 CPU was a real 
showstopper and a maintenance nightmare, and still having code to handle 
that misfeature would surely be a security hell nowadays too, so it had to 
go as soon as feasible.  As a nice side effect it let us get rid of the 
287/387 PC/AT-specific handling mess.

> With regards to EISA, you still haven't clarified if there is a true use 
> case or if this is a museum/nostalgia project. There isn't anything 
> *wrong* with museum projects, not at all (I recently got to play 
> SPACEWAR! on a real PDP-1; it was amazing) but imposing a maintenance 
> burden on the mainline developers of one of the most heavily used 
> architecture on the planet is not practical.

 There is no commercial value and no use case beyond making sure all the 
pieces involved continue to run.  You can call it a museum/nostalgia 
project if you prefer; for me it's the usual engineering challenge as 
with everything I do around Linux.

 As already stated in my reply to Borislav I don't want to put any burden 
on any maintainers and I'm trying to reduce it to zero while not losing 
the features.  The lone presence of a piece of code isn't a burden unless 
you actually have to do anything about it.

 I realise it's easier done with a niche kernel architecture than with one 
of the mainstream ones.

> If someone really wanted to, they could maybe fork off, say, arch/i486 
> and maintain the a version of the kernel limited to these old machines, 
> but it would require someone being willing to do the work.

 There's willingness and there's the availability of resources.  If it's 
say 2KiB worth of source code difference that you don't have to look at 
unless you run the platform that needs it, I'd argue I could maintain it, 
but question whether it's worth forking in the first place rather than 
keeping it in the main repo.

  Maciej

On Tue, 6 May 2025 at 09:44, H. Peter Anvin <hpa@zytor.com> wrote:
>
> a. Someone would have to take it on;
> b. It will need continuous testing;
> c. That someone would *also* have to go through the additional effort of keeping the mainline code clean for the maintainers of the modern hardware.

I think the main issue is "when problems happen, people who
*shouldn't* have to care get reports".

I really think that the way forward is basically what we did for ia64:
get rid of i486 support in mainline, and people who care about i486
can maintain a smallish patch that basically keeps it alive for them.

Because I suspect that the "patch to keep it working in practice" is
likely going to remain pretty small: it's the silly cmpxchg helper
wrappers, it's disabling ARCH_USE_CMPXCHG_LOCKREF, and probably a few
X86_FEATURE_CX8 tests.

And it probably (a) works fine and (b) won't be code that changs very
much upstream, so maintaining it outside the main tree is likely not a
lot of work.

But because it's outside of the main tree, it won't cause pointless
noise from 0day bots etc, and won't affect people who care about
modern machines. And it can do various hacky things because the patch
would *only* be used by people who actually run on an i486-class
machine.

(Ok, if you actually care about the i486SX, the patch will be much
bigger, because it will have that whole FPU emulation code in it)

             Linus

On Tue, 6 May 2025, Linus Torvalds wrote:

> > a. Someone would have to take it on;
> > b. It will need continuous testing;
> > c. That someone would *also* have to go through the additional effort of keeping the mainline code clean for the maintainers of the modern hardware.
> 
> I think the main issue is "when problems happen, people who
> *shouldn't* have to care get reports".

 FWIW I can't agree more here.

> I really think that the way forward is basically what we did for ia64:
> get rid of i486 support in mainline, and people who care about i486
> can maintain a smallish patch that basically keeps it alive for them.
> 
> Because I suspect that the "patch to keep it working in practice" is
> likely going to remain pretty small: it's the silly cmpxchg helper
> wrappers, it's disabling ARCH_USE_CMPXCHG_LOCKREF, and probably a few
> X86_FEATURE_CX8 tests.

 Why would these have to be disabled if we have CMPXCHG8B emulation?  Yes,
performance won't be stellar, but we talked it through already in the 
context of my recent EV4 Alpha effort.  People ran FPU emulation back in 
the day too rather than using soft-float, which would have surely reduced 
the handling overhead.

> And it probably (a) works fine and (b) won't be code that changs very
> much upstream, so maintaining it outside the main tree is likely not a
> lot of work.

 Conversely dropping support for a subtarget in the kernel will likely 
prompt the removal on the userland side, namely glibc, which will only 
complicate things.

> But because it's outside of the main tree, it won't cause pointless
> noise from 0day bots etc, and won't affect people who care about
> modern machines. And it can do various hacky things because the patch
> would *only* be used by people who actually run on an i486-class
> machine.

 This is a fair point, although I'm not sure why the bots are expected to 
complain about a piece of code once it's settled and does not change.  I 
can't recall any mailing list traffic about MIPS instruction emulation for 
legacy systems (and we made it a part of the uABI even) in what? -- 20 
years or so.

 And I'd prefer to stay away from hacks even at the cost of performance.  
I don't find the emulation of CMPXCHG8B and maybe RDTSC if really needed 
(possibly in a trivial way, such as returning an incrementing software 
counter) a hack, but evolution.  It has happened before.

> (Ok, if you actually care about the i486SX, the patch will be much
> bigger, because it will have that whole FPU emulation code in it)

 FWIW I'm fine to see FPU emulation code go, especially as it's something 
that can be sorted in the userland for the so inclined.  Or you can run a 
soft-float userland, for example in the form of a GCC multilib just as 
done with numerous targets.

  Maciej

On May 6, 2025 10:11:04 AM PDT, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>On Tue, 6 May 2025 at 09:44, H. Peter Anvin <hpa@zytor.com> wrote:
>>
>> a. Someone would have to take it on;
>> b. It will need continuous testing;
>> c. That someone would *also* have to go through the additional effort of keeping the mainline code clean for the maintainers of the modern hardware.
>
>I think the main issue is "when problems happen, people who
>*shouldn't* have to care get reports".
>
>I really think that the way forward is basically what we did for ia64:
>get rid of i486 support in mainline, and people who care about i486
>can maintain a smallish patch that basically keeps it alive for them.
>
>Because I suspect that the "patch to keep it working in practice" is
>likely going to remain pretty small: it's the silly cmpxchg helper
>wrappers, it's disabling ARCH_USE_CMPXCHG_LOCKREF, and probably a few
>X86_FEATURE_CX8 tests.
>
>And it probably (a) works fine and (b) won't be code that changs very
>much upstream, so maintaining it outside the main tree is likely not a
>lot of work.
>
>But because it's outside of the main tree, it won't cause pointless
>noise from 0day bots etc, and won't affect people who care about
>modern machines. And it can do various hacky things because the patch
>would *only* be used by people who actually run on an i486-class
>machine.
>
>(Ok, if you actually care about the i486SX, the patch will be much
>bigger, because it will have that whole FPU emulation code in it)
>
>             Linus

Yes, the patch will be bigger, but it's just a bunch of highly static code copied straight out of the current kernel with very few touch points to the rest of the kernel (which is why we didn't axe it together with i386 support. Now that one was ugly, with touch points all over the place.)

It is basically the same idea as the arch/i486 I suggested, just in a separate git tree (although I guess I don't really see how this is fundamentally different than, say, arch/m68k.)

An i486/i586 retroport can presumably also axe a bunch of things like side channel mitigations; most of them aren't applicable to the in-order i486/586 pipelines and the rest ... well, on a machine that slow, you are unlikely to be running the kind of workloads that care. 

Similarly, you should be able to simply unsupport the things that make the entry/exit code a nightmare, like SYSENTER and fancy NMI hacks (the latter requires an APIC.)

As far as I know, Transmeta Crusoe was the only i586-class CPU which supported SYSENTER (if that version of the firmware even shipped, I'm not sure), and Crusoe was "almost" i686 class in terms of ISA (mainly lacking PAE and NOPL, and having P5-like flags behavior.)

There is a huge gap then to the i686, with the i686 being the direct ancestor of the x86-64 systems in terms of systems architecture (APIC, PAE*, etc; SYSENTER in the second iteration; a general tightening of the ISA definition; PCI universal by then...)

But again, this is all academic unless someone steps up and wants to take on such a project.

   -hpa

* – I believe there was one version of the Pentium M which didn't have PAE, at least officially, although I understand that if you flipped the CR4 bit it actually worked. I am guessing, without any concrete evidence, that there was a timing path and that it would fail at the highest operating temperatures on some subset of chips.

On Tue, 6 May 2025, H. Peter Anvin wrote:

> An i486/i586 retroport can presumably also axe a bunch of things like 
> side channel mitigations; most of them aren't applicable to the in-order 
> i486/586 pipelines and the rest ... well, on a machine that slow, you 
> are unlikely to be running the kind of workloads that care.
> 
> Similarly, you should be able to simply unsupport the things that make 
> the entry/exit code a nightmare, like SYSENTER and fancy NMI hacks (the 
> latter requires an APIC.)

 I do have a dual i586 with an APIC; used it to work on some NMI watchdog 
stuff that landed in mainline 25+ years ago.  Back in the day such systems 
were pretty common, built around the NX or later the HX chipset, so it's 
not that APIC support is irrelevent could be dropped.  If we were to go 
for a separate port, than stuff could potentially be resurrected too that 
was previously removed, such as discrete i82489DX APIC support.

 NB that box actually still runs some server software I need for my lab 
(MOP daemon, needed to netboot various DEC equipment) that I haven't 
ported to POWER9 owing to higher priority items.

> There is a huge gap then to the i686, with the i686 being the direct 
> ancestor of the x86-64 systems in terms of systems architecture (APIC, 
> PAE*, etc; SYSENTER in the second iteration; a general tightening of the 
> ISA definition; PCI universal by then...)

 I suspect eventually we'll want to drop all IA-32 support from mainline; 
isn't it of no commercial relevance already?  Hasn't even the embedded x86 
ecosystem switched to 64-bit Atom and the like?

 Actually I think a project to maintain the whole IA-32 platform alive 
rather than just the i486 subtarget might attract more attention and 
people beyond just myself and Adrian.  So far I've committed to support 
across the board (Linux where applicable and the GNU toolchain) for DEC 
Alpha, MIPS and VAX platforms plus a couple of small pieces such as the 
defxx driver and I can hardly cope already, so taking on another large 
project just won't work if I were alone with it.

> But again, this is all academic unless someone steps up and wants to 
> take on such a project.

 Correct, I just want to keep support to the minimum at the moment.

  Maciej

On May 5, 2025 1:53:04 AM PDT, "Maciej W. Rozycki" <macro@orcam.me.uk> wrote:
>On Fri, 25 Apr 2025, Ingo Molnar wrote:
>
>>  > I really get the feeling that it's time to leave i486 support behind.
>>  > There's zero real reason for anybody to waste one second of
>>  > development effort on this kind of issue.
>> 
>> This series increases minimum kernel support features to include TSC and
>> CX8 (CMPXCHG8B) hardware support, which removes 486 (and derivatives) support
>> and early-586 (and derivatives) support.
>
> FWIW I'm not happy about that at the very least because this will prevent 
>me from using my 486 box for EISA defxx driver maintenance.  What exactly 
>is the problem with 486?
>
> I know the lack of TSC has security implications, but don't use the 
>machine in a way for which it would be an issue and I don't expect anyone 
>doing otherwise.  We have non-x86 platforms that lack a high-resolution 
>timer and nobody's going to drop them.
>
> We also have platforms that lack atomics, let alone double-precision ones 
>and they're fine too, so why is x86 different?
>
>  Maciej

Why is x86 different? Because it is a tightly integrated platform with code shared across a very large number of generations, without "silly embedded nonsense hacks."

I think if you have a use case, you need to speak up about it, rather than for people to guess.

On Mon, 5 May 2025, H. Peter Anvin wrote:

> >>  > I really get the feeling that it's time to leave i486 support behind.
> >>  > There's zero real reason for anybody to waste one second of
> >>  > development effort on this kind of issue.
> >> 
> >> This series increases minimum kernel support features to include TSC and
> >> CX8 (CMPXCHG8B) hardware support, which removes 486 (and derivatives) support
> >> and early-586 (and derivatives) support.
> >
> > FWIW I'm not happy about that at the very least because this will prevent 
> >me from using my 486 box for EISA defxx driver maintenance.  What exactly 
> >is the problem with 486?
> >
> > I know the lack of TSC has security implications, but don't use the 
> >machine in a way for which it would be an issue and I don't expect anyone 
> >doing otherwise.  We have non-x86 platforms that lack a high-resolution 
> >timer and nobody's going to drop them.
> >
> > We also have platforms that lack atomics, let alone double-precision ones 
> >and they're fine too, so why is x86 different?
> 
> Why is x86 different? Because it is a tightly integrated platform with 
> code shared across a very large number of generations, without "silly 
> embedded nonsense hacks."

 Thank you for the clarification.  By "silly embedded nonsense hacks" I 
suppose you refer to missing instruction emulation, which some platforms 
do so as to contain legacy support in a single place and let the rest of 
the code base assume the required feature is there, relieving maintainers 
from extra burden, correct?

> I think if you have a use case, you need to speak up about it, rather 
> than for people to guess.

 Which I just did; I think that's exactly what an RFC is about, isn't it?

  Maciej

On May 5, 2025 6:04:12 AM PDT, "Maciej W. Rozycki" <macro@orcam.me.uk> wrote:
>On Mon, 5 May 2025, H. Peter Anvin wrote:
>
>> >>  > I really get the feeling that it's time to leave i486 support behind.
>> >>  > There's zero real reason for anybody to waste one second of
>> >>  > development effort on this kind of issue.
>> >> 
>> >> This series increases minimum kernel support features to include TSC and
>> >> CX8 (CMPXCHG8B) hardware support, which removes 486 (and derivatives) support
>> >> and early-586 (and derivatives) support.
>> >
>> > FWIW I'm not happy about that at the very least because this will prevent 
>> >me from using my 486 box for EISA defxx driver maintenance.  What exactly 
>> >is the problem with 486?
>> >
>> > I know the lack of TSC has security implications, but don't use the 
>> >machine in a way for which it would be an issue and I don't expect anyone 
>> >doing otherwise.  We have non-x86 platforms that lack a high-resolution 
>> >timer and nobody's going to drop them.
>> >
>> > We also have platforms that lack atomics, let alone double-precision ones 
>> >and they're fine too, so why is x86 different?
>> 
>> Why is x86 different? Because it is a tightly integrated platform with 
>> code shared across a very large number of generations, without "silly 
>> embedded nonsense hacks."
>
> Thank you for the clarification.  By "silly embedded nonsense hacks" I 
>suppose you refer to missing instruction emulation, which some platforms 
>do so as to contain legacy support in a single place and let the rest of 
>the code base assume the required feature is there, relieving maintainers 
>from extra burden, correct?
>
>> I think if you have a use case, you need to speak up about it, rather 
>> than for people to guess.
>
> Which I just did; I think that's exactly what an RFC is about, isn't it?
>
>  Maciej

No, with "silly embedded nonsense hacks" (Google for it) I mean ad hoc hacks breaking the notion of a common platform.

As far as EISA is concerned, could you go into more detail? What are the remaining users of EISA? One thing that happened with i386 was that we found out that the only remaining "users" were people dragging out an old machine to test if the kernel still booted. With bigsmp we had similar experiences – in at least one case we ended up maintaining support for a system of which there were no machines left in existence...

On Mon, 5 May 2025, H. Peter Anvin wrote:

> >> I think if you have a use case, you need to speak up about it, rather 
> >> than for people to guess.
> >
> > Which I just did; I think that's exactly what an RFC is about, isn't it?
> 
> No, with "silly embedded nonsense hacks" (Google for it) I mean ad hoc 
> hacks breaking the notion of a common platform.

 I don't feel like I'm the right person to talk about such stuff.  I've 
always cared about portability and standardisation.

 In fact running old hardware is one aspect of portability verification, 
for example I run PCIe stuff off my Pentium MMX and Alpha hardware, and 
conversely I run conventional PCI stuff off my POWER9 (no port I/O!) and 
RISC-V hardware.  That has triggered numerous bugs, fixed over the years.

> As far as EISA is concerned, could you go into more detail? What are the 
> remaining users of EISA? One thing that happened with i386 was that we 
> found out that the only remaining "users" were people dragging out an 
> old machine to test if the kernel still booted. With bigsmp we had 
> similar experiences – in at least one case we ended up maintaining 
> support for a system of which there were no machines left in 
> existence...

 Well, my i486 box is plain EISA, so naturally I need EISA support to run 
it:

platform eisa.0: Probing EISA bus 0
eisa 00:00: EISA: Mainboard AEI0401 detected
eisa 00:05: EISA: slot 5: DEC3002 detected
defxx: v1.12 2021/03/10  Lawrence V. Stefani and others
00:05: DEFEA at I/O addr = 0x5000, IRQ = 10, Hardware addr = 00-00-f8-xx-yy-zz
00:05: registered as fddi0
eisa 00:06: EISA: slot 6: NPI0303 detected
eisa 00:08: EISA: slot 8: TCM5094 detected
eth0: 3c5x9 found at 0x8000, 10baseT port, address 00:a0:24:xx:yy:zz, IRQ 12.
platform eisa.0: EISA: Detected 3 cards

(fddi0 is the fast intranet interface, eth0 is the slow external one).  
It's a luggable integrated computer BTW, a Dolch PAC 60, very nice and 
compact, previously used by a field engineer for network fault isolation.

 I've already mentioned the maintenance of the defxx driver (it is also an 
exercise in portability, with defxx supporting 3 host bus attachments).

 This is also my backup box for GNU toolchain (GCC/glibc/GDB) verification 
for the i386 target.  It has actually proved recently to still have some 
commercial relevance (again, for portability verification), but who says 
the use of Linux is supposed to be solely commercial even nowadays?

 The origin of Linux is obvious and I wouldn't be around at all let alone 
for so many years if not for my enthusiasm solely for the technical merit 
of Linux (following my earlier passion for processors and systems) 
accompanied by the fairness of the GNU GPL, with any commercial aspect 
being at most distantly relevant and a late comer into the game.

 So yes, count me in as a passionate systems software engineer with a 
fondness for running odd configurations for the sake of experimentation 
(and consequently a portability exercise) and please do not deprive me of 
my enthusiasm.

  Maciej

On Tue, 2025-05-06 at 14:48 +0100, Maciej W. Rozycki wrote:
>  In fact running old hardware is one aspect of portability verification, 
> for example I run PCIe stuff off my Pentium MMX and Alpha hardware, and 
> conversely I run conventional PCI stuff off my POWER9 (no port I/O!) and 
> RISC-V hardware.  That has triggered numerous bugs, fixed over the years.

I agree with that stance. Building and running Debian on various architectures
has enabled use to find obscure bugs that did not trigger easily on x86_64
or arm64.

I remember one nasty bug in the DMA code that initially showed on ia64 only
and it was only when someone finally ran into the same problem on x86_64 that
it was actually fixed.

> 
> (fddi0 is the fast intranet interface, eth0 is the slow external one).  
> It's a luggable integrated computer BTW, a Dolch PAC 60, very nice and 
> compact, previously used by a field engineer for network fault isolation.
> 
>  I've already mentioned the maintenance of the defxx driver (it is also an 
> exercise in portability, with defxx supporting 3 host bus attachments).
> 
>  This is also my backup box for GNU toolchain (GCC/glibc/GDB) verification 
> for the i386 target.  It has actually proved recently to still have some 
> commercial relevance (again, for portability verification), but who says 
> the use of Linux is supposed to be solely commercial even nowadays?

I fully agree with this. Cross-architecture testing really helps finding hidden
bugs and it's also fun ;-).

>  The origin of Linux is obvious and I wouldn't be around at all let alone 
> for so many years if not for my enthusiasm solely for the technical merit 
> of Linux (following my earlier passion for processors and systems) 
> accompanied by the fairness of the GNU GPL, with any commercial aspect 
> being at most distantly relevant and a late comer into the game.
> 
>  So yes, count me in as a passionate systems software engineer with a 
> fondness for running odd configurations for the sake of experimentation 
> (and consequently a portability exercise) and please do not deprive me of 
> my enthusiasm.

Count me in as well.

PS: No, we don't have to bring back ia64 for that matter ;-).

Adrian

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

On Mon, May 05, 2025 at 12:57:40PM -0700, H. Peter Anvin wrote:
> One thing that happened with i386 was that we found out that the only
> remaining "users" were people dragging out an old machine to test if the
> kernel still booted.

Follow this thread:

https://lore.kernel.org/r/CANpbe9Wm3z8fy9HbgS8cuhoj0TREYEEkBipDuhgkWFvqX0UoVQ@mail.gmail.com

People booting latest kernel on 486 without CPUID support. 

I can't find it in me to care for that old rust and yet I did it again. :-\

So yeah, +1 for removing old code which ain't worth maintaining.

There's stable and older kernels, those folks can use those and that's it.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

On Mon, 5 May 2025, Borislav Petkov wrote:

> > One thing that happened with i386 was that we found out that the only
> > remaining "users" were people dragging out an old machine to test if the
> > kernel still booted.
> 
> Follow this thread:
> 
> https://lore.kernel.org/r/CANpbe9Wm3z8fy9HbgS8cuhoj0TREYEEkBipDuhgkWFvqX0UoVQ@mail.gmail.com
> 
> People booting latest kernel on 486 without CPUID support. 

 No such hardware here:

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 4
model		: 3
model name	: 486 DX/2
stepping	: 5
fdiv_bug	: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme cpuid
bugs		: itlb_multihit
bogomips	: 32.56
clflush size	: 32
cache_alignment	: 32
address sizes	: 32 bits physical, 32 bits virtual
power management:

Sadly it's not one with 4MiB page support (that would be stepping 6).

> There's stable and older kernels, those folks can use those and that's it.

 Doesn't work for ongoing driver maintenance (and yes, distractions such 
as this only keep me from taking care of outstanding stuff, like figuring 
out why the defxx driver reproducibly crashes with my POWER9 box running 
glibc verification remotely for my RISC-V box; it's all intertwined and an 
issue in one place affects other ones, sigh).

  Maciej

On Tue, May 06, 2025 at 02:51:51PM +0100, Maciej W. Rozycki wrote:
>  Doesn't work for ongoing driver maintenance

Dunno, I'd concentrate my efforts on something, a *little* *bit* more modern.
At some point this is old rusty hw no matter from which way you look at it and
it might as well be left to rest in its sunset days.

But I certainly am not trying to tell you what to do with your time.

What I have problem with is wasting my time maintaining old, ancient hw which
is not worth the electricity it needs to run. Especially if you can get
something orders of magnitudes better in *any* aspect you can think of, and
actually get some real work done.

:-P

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

On Tue, 6 May 2025, Borislav Petkov wrote:

> >  Doesn't work for ongoing driver maintenance
> 
> Dunno, I'd concentrate my efforts on something, a *little* *bit* more modern.
> At some point this is old rusty hw no matter from which way you look at it and
> it might as well be left to rest in its sunset days.

 One doesn't exclude the other.  I do POWER9 or RISC-V stuff too.  Isn't 
it modern enough?

> What I have problem with is wasting my time maintaining old, ancient hw which
> is not worth the electricity it needs to run. Especially if you can get
> something orders of magnitudes better in *any* aspect you can think of, and
> actually get some real work done.

 I don't want you let alone expect to waste time on anything you're not 
interested in.  I'm trying to find a solution that saves you from that 
while preferably keeping everyone happy enough, including myself.

 Real work?  I find engineering challenges enjoyable regardless of the age 
of hardware involved and I don't want to take away anyone's daily bread 
(including mine) by spending my free time on a project someone might have 
commercial interest in and should pay for.  An obsolete platform is ideal 
for this purpose.

 And what's better and what's not is subjective.  I don't find all the new 
stuff better, just as I don't all the old stuff.  At least the old gear 
tends to be sturdy (once you've contained issues with the PSU) and likely 
won't suffer from electromigration in a few years' time.  It can be easier 
to repair too if a component does fail.

 NB people also fancy old cars, or boats, or trains even, not because 
they're faster, more comfortable, or have any real advantage over modern 
alternatives.

  Maciej

On May 8, 2025 4:51:27 PM GMT+02:00, "Maciej W. Rozycki" <macro@orcam.me.uk> wrote:
>On Tue, 6 May 2025, Borislav Petkov wrote:
>
>> >  Doesn't work for ongoing driver maintenance
>> 
>> Dunno, I'd concentrate my efforts on something, a *little* *bit* more modern.
>> At some point this is old rusty hw no matter from which way you look at it and
>> it might as well be left to rest in its sunset days.
>
> One doesn't exclude the other.  I do POWER9 or RISC-V stuff too.  Isn't 
>it modern enough?
>
>> What I have problem with is wasting my time maintaining old, ancient hw which
>> is not worth the electricity it needs to run. Especially if you can get
>> something orders of magnitudes better in *any* aspect you can think of, and
>> actually get some real work done.
>
> I don't want you let alone expect to waste time on anything you're not 
>interested in.  I'm trying to find a solution that saves you from that 
>while preferably keeping everyone happy enough, including myself.
>
> Real work?  I find engineering challenges enjoyable regardless of the age 
>of hardware involved and I don't want to take away anyone's daily bread 
>(including mine) by spending my free time on a project someone might have 
>commercial interest in and should pay for.  An obsolete platform is ideal 
>for this purpose.
>
> And what's better and what's not is subjective.  I don't find all the new 
>stuff better, just as I don't all the old stuff.  At least the old gear 
>tends to be sturdy (once you've contained issues with the PSU) and likely 
>won't suffer from electromigration in a few years' time.  It can be easier 
>to repair too if a component does fail.
>
> NB people also fancy old cars, or boats, or trains even, not because 
>they're faster, more comfortable, or have any real advantage over modern 
>alternatives.


This fits very well, IMO, with Linus' suggestion to support this stuff out of tree. I think this solution is the optimal one for all parties involved...

-- 
Sent from a small device: formatting sucks and brevity is inevitable.

On Thu, 8 May 2025, Borislav Petkov wrote:

> > NB people also fancy old cars, or boats, or trains even, not because 
> >they're faster, more comfortable, or have any real advantage over modern 
> >alternatives.
> 
> 
> This fits very well, IMO, with Linus' suggestion to support this stuff 
> out of tree. I think this solution is the optimal one for all parties 
> involved...

 Would kernel.org git infrastructure be available for such a project?

  Maciej

On Mon, May 12, 2025 at 01:55:35PM +0100, Maciej W. Rozycki wrote:
> On Thu, 8 May 2025, Borislav Petkov wrote:
> 
> > > NB people also fancy old cars, or boats, or trains even, not because 
> > >they're faster, more comfortable, or have any real advantage over modern 
> > >alternatives.
> > 
> > 
> > This fits very well, IMO, with Linus' suggestion to support this stuff 
> > out of tree. I think this solution is the optimal one for all parties 
> > involved...
> 
>  Would kernel.org git infrastructure be available for such a project?

as in hosting your repo there?

I don't see why not:

https://korg.docs.kernel.org/accounts.html

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

On Mon, 12 May 2025, Borislav Petkov wrote:

> >  Would kernel.org git infrastructure be available for such a project?
> 
> as in hosting your repo there?
> 
> I don't see why not:
> 
> https://korg.docs.kernel.org/accounts.html

 Thank you.  It seems it'll be tough for me though to fulfil the GPG key 
trustability requirement.  While I've used PGP/GPG since 1995, I haven't 
been active collecting signatures with my more recent keys/IDs and neither 
I have appeared in public among Linux kernel developers often enough for 
me to be identified by face over a video call.  Oh well...

  Maciej

On Mon, May 12, 2025 at 10:29 AM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>
>  Thank you.  It seems it'll be tough for me though to fulfil the GPG key
> trustability requirement.  While I've used PGP/GPG since 1995, I haven't
> been active collecting signatures with my more recent keys/IDs and neither
> I have appeared in public among Linux kernel developers often enough for
> me to be identified by face over a video call.  Oh well...

I don't think this has been insurmountable before, particularly for
anybody who has been around for as long as you have.  Even your
current email goes back to at least the beginnings of git.

If "two decades+ of active kernel development involvement using the
same email address" doesn't make you eligible for a kernel.org
account, we're doing something wrong.

                Linus

Hi,

On Mon, 2025-05-12 at 19:00 -0700, Linus Torvalds wrote:
> On Mon, May 12, 2025 at 10:29 AM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> > 
> >  Thank you.  It seems it'll be tough for me though to fulfil the GPG key
> > trustability requirement.  While I've used PGP/GPG since 1995, I haven't
> > been active collecting signatures with my more recent keys/IDs and neither
> > I have appeared in public among Linux kernel developers often enough for
> > me to be identified by face over a video call.  Oh well...
> 
> I don't think this has been insurmountable before, particularly for
> anybody who has been around for as long as you have.  Even your
> current email goes back to at least the beginnings of git.
> 
> If "two decades+ of active kernel development involvement using the
> same email address" doesn't make you eligible for a kernel.org
> account, we're doing something wrong.

I agree. Maciej does a fantastic job saving old junk^W^Wretro hardware ;-).

I'm sure there should be anyone in Maciej's area that could sign his keys.

Adrian

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

On Tue, 13 May 2025, John Paul Adrian Glaubitz wrote:

> > >  Thank you.  It seems it'll be tough for me though to fulfil the GPG key
> > > trustability requirement.  While I've used PGP/GPG since 1995, I haven't
> > > been active collecting signatures with my more recent keys/IDs and neither
> > > I have appeared in public among Linux kernel developers often enough for
> > > me to be identified by face over a video call.  Oh well...
> > 
> > I don't think this has been insurmountable before, particularly for
> > anybody who has been around for as long as you have.  Even your
> > current email goes back to at least the beginnings of git.

 Hmm, a .mailmap artifact perhaps; I actually only switched to my current 
e-mail address back in 2021 once linux-mips.org has lost all the remaining 
credibility in my eyes.  There's exactly one "Patch-dusted-off-by:" commit 
using my yet earlier personal address, plus a bunch using my various old 
work addresses too.

 All the earlier work has been buried either in the linux-mips.org git 
repo, going back via conversion from CVS to:

commit 1513ff9b7899ab588401c89db0e99903dbf5f886
Author: Ralf Baechle <ralf@linux-mips.org>
Date:   Mon Nov 28 11:59:19 1994 +0000

    Import of Linus's Linux 1.1.68

(which I still do hope to fully recover and for which kernel.org seems to 
be the right ultimate haven), or in LKML and other mailing list archives.

 None of this however proves any GPG key offered is actually mine.

> > If "two decades+ of active kernel development involvement using the
> > same email address" doesn't make you eligible for a kernel.org
> > account, we're doing something wrong.
> 
> I agree. Maciej does a fantastic job saving old junk^W^Wretro hardware ;-).

 Thank you.  That makes two of us; the rest has switched to NetBSD.

> I'm sure there should be anyone in Maciej's area that could sign his keys.

 Undoubtedly, but finding someone local who has a kernel.org account and 
can actually tell I am who I claim I am will be rather tough, and trusting 
a government-issued ID alone may be questionable nowadays, as correctly 
observed in <https://korg.docs.kernel.org/accounts.html#pgp-web-of-trust>.

  Maciej

On Tue, 13 May 2025 at 14:55, Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>
>  Hmm, a .mailmap artifact perhaps

Ahh, indeed. I was looking at commit feea1db26e5b ("[PATCH] defxx: Use
irqreturn_t for the interrupt handler") from 2005, but yes, the raw
commit information has your linux-mips address, and it's just that
"git log" will translate it to something much newer...

But I really don't think we've ever been *so* strict about pgp keys
having all the proper pgp key signature chains. Yes, it's the normal
rule and the regular way people identify themselves, but nothing
should ever be mindlessly black-and-white.

               Linus

On Tue, 13 May 2025, Linus Torvalds wrote:

> But I really don't think we've ever been *so* strict about pgp keys
> having all the proper pgp key signature chains. Yes, it's the normal
> rule and the regular way people identify themselves, but nothing
> should ever be mindlessly black-and-white.

 I agree about being reasonable.  However times are such that we need to 
be extremely vigilant.  I wish we were back in the 1990s when the worst 
threat online seemed to be unsolicited offers received via e-mail for 
various enlargement treatments; sadly not for the brain.

  Maciej

On 5/13/25 15:02, Linus Torvalds wrote:
> On Tue, 13 May 2025 at 14:55, Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>>
>>   Hmm, a .mailmap artifact perhaps
> 
> Ahh, indeed. I was looking at commit feea1db26e5b ("[PATCH] defxx: Use
> irqreturn_t for the interrupt handler") from 2005, but yes, the raw
> commit information has your linux-mips address, and it's just that
> "git log" will translate it to something much newer...
> 
> But I really don't think we've ever been *so* strict about pgp keys
> having all the proper pgp key signature chains. Yes, it's the normal
> rule and the regular way people identify themselves, but nothing
> should ever be mindlessly black-and-white.

Having the discussion with Maciej offlist.

The issue here is obviously not that Maciej is qualified to have a 
kernel.org account (I consider that to be a given), but that we need to 
avoid a "Jia Tan" incident.

	-hpa

On May 12, 2025 7:00:55 PM PDT, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>On Mon, May 12, 2025 at 10:29 AM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>>
>>  Thank you.  It seems it'll be tough for me though to fulfil the GPG key
>> trustability requirement.  While I've used PGP/GPG since 1995, I haven't
>> been active collecting signatures with my more recent keys/IDs and neither
>> I have appeared in public among Linux kernel developers often enough for
>> me to be identified by face over a video call.  Oh well...
>
>I don't think this has been insurmountable before, particularly for
>anybody who has been around for as long as you have.  Even your
>current email goes back to at least the beginnings of git.
>
>If "two decades+ of active kernel development involvement using the
>same email address" doesn't make you eligible for a kernel.org
>account, we're doing something wrong.
>
>                Linus
>

Yeah, we have dealt with this before :)