[PATCH v2] x86: Start removing X86_X32_ABI

[PATCH v2] x86: Start removing X86_X32_ABI

[Sebastian Andrzej Siewior]

The x32 ABI was introduced in v3.4 to leverage the additional registers
which were available on x86_64 but not on i386 while keeping the smaller
32bit pointers.

This did not take off. The memory usage usually knows no limit and the
better performance did not reach a point where certain workloads widely
move to x32 and use it exclusively. In the meantime Debian introduced a
patch to disable x32 by default (so it has to be enabled at boot time on
the command line) because they are afraid of the increased attack
surface. Fedora as far as I tell has X32 disabled (looking at 7.0-rc5
rpm in rawhide).

The syscall range >512 used by x32 can not be reused because on earlier
kernels (before v5.4 with x32 enabled, see commit 6365b842aae4
("x86/syscalls: Split the x32 syscalls into their own table") it is not
obvious if the syscall is for x86-64 and not implemented or meant for
x32.
What can be removed are the special compat cases due to different
alignment.

Since there is practically no real use for x32, start removing it by
removing the symbol first, not allowing to enable it. Should nothing
happening by the end of the year, it will removed after the last LTS
kernel this year.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---

v1…v2: https://lore.kernel.org/r/20260523093734.A3AR7reJ@linutronix.de
 - reword commit description, don't claim the syscall range can be
   used.

 arch/x86/Kconfig | 14 --------------
 1 file changed, 14 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index bdad90f210e4b..f6fe55fdc928a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -3097,20 +3097,6 @@ config IA32_EMULATION_DEFAULT_DISABLED
 	  processes and access to 32-bit syscalls. If unsure, leave it to its
 	  default value.
 
-config X86_X32_ABI
-	bool "x32 ABI for 64-bit mode"
-	depends on X86_64
-	# llvm-objcopy does not convert x86_64 .note.gnu.property or
-	# compressed debug sections to x86_x32 properly:
-	# https://github.com/ClangBuiltLinux/linux/issues/514
-	# https://github.com/ClangBuiltLinux/linux/issues/1141
-	depends on $(success,$(OBJCOPY) --version | head -n1 | grep -qv llvm)
-	help
-	  Include code to run binaries for the x32 native 32-bit ABI
-	  for 64-bit processors.  An x32 process gets access to the
-	  full 64-bit register file and wide data path while leaving
-	  pointers at 32 bits for smaller memory footprint.
-
 config COMPAT_32
 	def_bool y
 	depends on IA32_EMULATION || X86_32
-- 
2.53.0

Re: [PATCH v2] x86: Start removing X86_X32_ABI

[Arnd Bergmann]

On Tue, Jul 7, 2026, at 23:22, Sebastian Andrzej Siewior wrote:
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
>
> v1…v2: https://lore.kernel.org/r/20260523093734.A3AR7reJ@linutronix.de
>  - reword commit description, don't claim the syscall range can be
>    used.

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

Re: [PATCH v2] x86: Start removing X86_X32_ABI

[John Paul Adrian Glaubitz]

Hello,

On Tue, 2026-07-07 at 23:22 +0200, Sebastian Andrzej Siewior wrote:
> The x32 ABI was introduced in v3.4 to leverage the additional registers
> which were available on x86_64 but not on i386 while keeping the smaller
> 32bit pointers.
> 
> This did not take off. The memory usage usually knows no limit and the
> better performance did not reach a point where certain workloads widely
> move to x32 and use it exclusively. In the meantime Debian introduced a
> patch to disable x32 by default (so it has to be enabled at boot time on
> the command line) because they are afraid of the increased attack
> surface. Fedora as far as I tell has X32 disabled (looking at 7.0-rc5
> rpm in rawhide).
> 
> The syscall range >512 used by x32 can not be reused because on earlier
> kernels (before v5.4 with x32 enabled, see commit 6365b842aae4
> ("x86/syscalls: Split the x32 syscalls into their own table") it is not
> obvious if the syscall is for x86-64 and not implemented or meant for
> x32.
> What can be removed are the special compat cases due to different
> alignment.
> 
> Since there is practically no real use for x32, start removing it by
> removing the symbol first, not allowing to enable it. Should nothing
> happening by the end of the year, it will removed after the last LTS
> kernel this year.

As mentioned before, there are still actively maintained Debian and Gentoo
ports of x32, so I guess the last paragraph is rather subjective.

Adrian

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

Re: [PATCH v2] x86: Start removing X86_X32_ABI

[Sebastian Andrzej Siewior]

On 2026-07-08 08:31:30 [+0200], John Paul Adrian Glaubitz wrote:
> Hello,
Hi,

> > Since there is practically no real use for x32, start removing it by
> > removing the symbol first, not allowing to enable it. Should nothing
> > happening by the end of the year, it will removed after the last LTS
> > kernel this year.
> 
> As mentioned before, there are still actively maintained Debian and Gentoo
> ports of x32, so I guess the last paragraph is rather subjective.

On the Debian ports side: lacks a browser like firefox or chromium. No
native ocaml compiler. libreoffice is not present.
Not once released in contrast to kFreeBSD.

This does not look like healthy port that will become eventually a
release architecture. To quote the introduction paragraph of ports.d.o:
| The goal of this machine is to provide an infrastructure for unofficial
| architectures until they are integrated in the main Debian archive.

> Adrian

Sebastian

Re: [PATCH v2] x86: Start removing X86_X32_ABI

[Arnd Bergmann]

On Wed, Jul 8, 2026, at 09:36, Sebastian Andrzej Siewior wrote:
> On 2026-07-08 08:31:30 [+0200], John Paul Adrian Glaubitz wrote:
>> > Since there is practically no real use for x32, start removing it by
>> > removing the symbol first, not allowing to enable it. Should nothing
>> > happening by the end of the year, it will removed after the last LTS
>> > kernel this year.
>> 
>> As mentioned before, there are still actively maintained Debian and Gentoo
>> ports of x32, so I guess the last paragraph is rather subjective.
>
> On the Debian ports side: lacks a browser like firefox or chromium. No
> native ocaml compiler. libreoffice is not present.
> Not once released in contrast to kFreeBSD.
>
> This does not look like healthy port that will become eventually a
> release architecture. To quote the introduction paragraph of ports.d.o:
> | The goal of this machine is to provide an infrastructure for unofficial
> | architectures until they are integrated in the main Debian archive.

x32 is a bit different since you can't have a pure x32 distro
anyway but always need to install an x86_64 distro first
to get a working kernel and base system before you can choose
a mix 32-bit and 64-bit packages. This is not that different
from armhf and i686, which run fine on 64-bit hardware but
always require you to start with a 64-bit installer. [for
different reasons though: armhf has an installer but its
kernel only works on 32-bit machines; i686 kernels can
theoretically run on older 64-bit hardware but Debian
no longer provides an installer for it]

As far as I understand, the typical use case for debian-x32 is
to run just a single performance-critical application, either
using "dpkg --add-architecture" or mmdebstrap/schroot. I used
to do that for having a faster gcc a decade ago when I was using
x86 build machines, though these days that probably fails
due to the linker running out of virtual memory in large
configurations.

Either approach can keep working using Debian Forky as the host
distro as long as that gets security updates for linux-image-7.3,
presumaby mid-2032 for LTS or at the latest 2037 with the
ELTS/SLTS kernels. This does require a choice for the Debian
x32 team though: either freeze userspace to Forky as well for
compatibility with 'dpkg --add-architecture', or stay on
unstable/testing and only allow schroot installs going forward.

My guess is that it's similar for Gentoo, which doesn't have
an x32 installer or kernel package either, though their kernel
support times are apparently much shorter than Debian's.

        Arnd

Re: [PATCH v2] x86: Start removing X86_X32_ABI

[Richard Purdie]

On Wed, 2026-07-08 at 13:26 +0200, Arnd Bergmann wrote:
> On Wed, Jul 8, 2026, at 09:36, Sebastian Andrzej Siewior wrote:
> > On 2026-07-08 08:31:30 [+0200], John Paul Adrian Glaubitz wrote:
> > > > Since there is practically no real use for x32, start removing
> > > > it by
> > > > removing the symbol first, not allowing to enable it. Should
> > > > nothing
> > > > happening by the end of the year, it will removed after the
> > > > last LTS
> > > > kernel this year.
> > > 
> > > As mentioned before, there are still actively maintained Debian
> > > and Gentoo
> > > ports of x32, so I guess the last paragraph is rather subjective.
> > 
> > On the Debian ports side: lacks a browser like firefox or chromium.
> > No
> > native ocaml compiler. libreoffice is not present.
> > Not once released in contrast to kFreeBSD.
> > 
> > This does not look like healthy port that will become eventually a
> > release architecture. To quote the introduction paragraph of
> > ports.d.o:
> > > The goal of this machine is to provide an infrastructure for
> > > unofficial
> > > architectures until they are integrated in the main Debian
> > > archive.
> 
> x32 is a bit different since you can't have a pure x32 distro
> anyway but always need to install an x86_64 distro first
> to get a working kernel and base system before you can choose
> a mix 32-bit and 64-bit packages. This is not that different
> from armhf and i686, which run fine on 64-bit hardware but
> always require you to start with a 64-bit installer. [for
> different reasons though: armhf has an installer but its
> kernel only works on 32-bit machines; i686 kernels can
> theoretically run on older 64-bit hardware but Debian
> no longer provides an installer for it]

FWIW Yocto Project (which cross compiles) can happily build x32 images
and has been able to for years, basically since it was added to the
kernel. It can also mix 32, x32 and 64 bit binaries (and supported n32
on mips too). We do test them nightly under qemu, I think including
boot tests under qemu but I'd have to double check if we still do.

It is very unclear that anyone uses x32 though. If the kernel drops
support, we'll just follow.

Cheers,

Richard

Re: [PATCH v2] x86: Start removing X86_X32_ABI

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 3086 bytes --]

"Arnd Bergmann" <arnd@arndb.de> writes:

> On Wed, Jul 8, 2026, at 09:36, Sebastian Andrzej Siewior wrote:
>> On 2026-07-08 08:31:30 [+0200], John Paul Adrian Glaubitz wrote:
>>> > Since there is practically no real use for x32, start removing it by
>>> > removing the symbol first, not allowing to enable it. Should nothing
>>> > happening by the end of the year, it will removed after the last LTS
>>> > kernel this year.
>>> 
>>> As mentioned before, there are still actively maintained Debian and Gentoo
>>> ports of x32, so I guess the last paragraph is rather subjective.
>>
>> On the Debian ports side: lacks a browser like firefox or chromium. No
>> native ocaml compiler. libreoffice is not present.
>> Not once released in contrast to kFreeBSD.
>>
>> This does not look like healthy port that will become eventually a
>> release architecture. To quote the introduction paragraph of ports.d.o:
>> | The goal of this machine is to provide an infrastructure for unofficial
>> | architectures until they are integrated in the main Debian archive.
>
> x32 is a bit different since you can't have a pure x32 distro
> anyway but always need to install an x86_64 distro first
> to get a working kernel and base system before you can choose
> a mix 32-bit and 64-bit packages. This is not that different
> from armhf and i686, which run fine on 64-bit hardware but
> always require you to start with a 64-bit installer. [for
> different reasons though: armhf has an installer but its
> kernel only works on 32-bit machines; i686 kernels can
> theoretically run on older 64-bit hardware but Debian
> no longer provides an installer for it]
>
> As far as I understand, the typical use case for debian-x32 is
> to run just a single performance-critical application, either
> using "dpkg --add-architecture" or mmdebstrap/schroot. I used
> to do that for having a faster gcc a decade ago when I was using
> x86 build machines, though these days that probably fails
> due to the linker running out of virtual memory in large
> configurations.
>
> Either approach can keep working using Debian Forky as the host
> distro as long as that gets security updates for linux-image-7.3,
> presumaby mid-2032 for LTS or at the latest 2037 with the
> ELTS/SLTS kernels. This does require a choice for the Debian
> x32 team though: either freeze userspace to Forky as well for
> compatibility with 'dpkg --add-architecture', or stay on
> unstable/testing and only allow schroot installs going forward.
>
> My guess is that it's similar for Gentoo, which doesn't have
> an x32 installer or kernel package either, though their kernel
> support times are apparently much shorter than Debian's.

No, there are people who actually use pure x32 without any sort of
multilib on Gentoo.

Someone even noticed when we broke our live media for it:
https://bugs.gentoo.org/908599.

Are there masses of these people? No, I don't believe so, and
I'm not going to strenuously object to its removal, but there are users
of it.

>
>         Arnd

sam

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 418 bytes --]

Re: [PATCH v2] x86: Start removing X86_X32_ABI

[Sebastian Andrzej Siewior]

On 2026-07-08 13:26:45 [+0200], Arnd Bergmann wrote:
> On Wed, Jul 8, 2026, at 09:36, Sebastian Andrzej Siewior wrote:
> > On 2026-07-08 08:31:30 [+0200], John Paul Adrian Glaubitz wrote:
> >> > Since there is practically no real use for x32, start removing it by
> >> > removing the symbol first, not allowing to enable it. Should nothing
> >> > happening by the end of the year, it will removed after the last LTS
> >> > kernel this year.
> >> 
> >> As mentioned before, there are still actively maintained Debian and Gentoo
> >> ports of x32, so I guess the last paragraph is rather subjective.
> >
> > On the Debian ports side: lacks a browser like firefox or chromium. No
> > native ocaml compiler. libreoffice is not present.
> > Not once released in contrast to kFreeBSD.
> >
> > This does not look like healthy port that will become eventually a
> > release architecture. To quote the introduction paragraph of ports.d.o:
> > | The goal of this machine is to provide an infrastructure for unofficial
> > | architectures until they are integrated in the main Debian archive.
> 
> x32 is a bit different since you can't have a pure x32 distro
Why not?

> anyway but always need to install an x86_64 distro first
> to get a working kernel and base system before you can choose
> a mix 32-bit and 64-bit packages. This is not that different
> from armhf and i686, which run fine on 64-bit hardware but

You simply lack a Debian installer/ boot+install medium. Some ports
architectures to provide netboot images
	https://get.debian.org/images/ports/snapshots/2026-06-12/

> always require you to start with a 64-bit installer. [for
> different reasons though: armhf has an installer but its
> kernel only works on 32-bit machines; i686 kernels can
> theoretically run on older 64-bit hardware but Debian
> no longer provides an installer for it]
>
> As far as I understand, the typical use case for debian-x32 is
> to run just a single performance-critical application, either
> using "dpkg --add-architecture" or mmdebstrap/schroot. I used
> to do that for having a faster gcc a decade ago when I was using
> x86 build machines, though these days that probably fails
> due to the linker running out of virtual memory in large
> configurations.

The "problem" with not being part of the main distro ist that you can't
have the packages say from Trixie and have security updates along with
it. Instead you always track Sid or don't update.

> Either approach can keep working using Debian Forky as the host
> distro as long as that gets security updates for linux-image-7.3,
> presumaby mid-2032 for LTS or at the latest 2037 with the
> ELTS/SLTS kernels. This does require a choice for the Debian
> x32 team though: either freeze userspace to Forky as well for
> compatibility with 'dpkg --add-architecture', or stay on
> unstable/testing and only allow schroot installs going forward.
> 
> My guess is that it's similar for Gentoo, which doesn't have
> an x32 installer or kernel package either, though their kernel
> support times are apparently much shorter than Debian's.
> 
>         Arnd

Sebastian

Re: [PATCH v2] x86: Start removing X86_X32_ABI

[John Paul Adrian Glaubitz]

On Wed, 2026-07-08 at 13:22 +0100, Sam James wrote:
> > My guess is that it's similar for Gentoo, which doesn't have
> > an x32 installer or kernel package either, though their kernel
> > support times are apparently much shorter than Debian's.
> 
> No, there are people who actually use pure x32 without any sort of
> multilib on Gentoo.
> 
> Someone even noticed when we broke our live media for it:
> https://bugs.gentoo.org/908599.
> 
> Are there masses of these people? No, I don't believe so, and
> I'm not going to strenuously object to its removal, but there are users
> of it.

Jepp, that's how I see it as well. I don't have particularly strong feelings
against the removal. But I think it should be well justified before breaking
something that people use.

Adrian 

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

Re: [PATCH v2] x86: Start removing X86_X32_ABI

[Arnd Bergmann]

On Wed, Jul 8, 2026, at 14:33, Sebastian Andrzej Siewior wrote:
> On 2026-07-08 13:26:45 [+0200], Arnd Bergmann wrote:
>> On Wed, Jul 8, 2026, at 09:36, Sebastian Andrzej Siewior wrote:
>> > On 2026-07-08 08:31:30 [+0200], John Paul Adrian Glaubitz wrote:
>> >> > Since there is practically no real use for x32, start removing it by
>> >> > removing the symbol first, not allowing to enable it. Should nothing
>> >> > happening by the end of the year, it will removed after the last LTS
>> >> > kernel this year.
>> >> 
>> >> As mentioned before, there are still actively maintained Debian and Gentoo
>> >> ports of x32, so I guess the last paragraph is rather subjective.
>> >
>> > On the Debian ports side: lacks a browser like firefox or chromium. No
>> > native ocaml compiler. libreoffice is not present.
>> > Not once released in contrast to kFreeBSD.
>> >
>> > This does not look like healthy port that will become eventually a
>> > release architecture. To quote the introduction paragraph of ports.d.o:
>> > | The goal of this machine is to provide an infrastructure for unofficial
>> > | architectures until they are integrated in the main Debian archive.
>> 
>> x32 is a bit different since you can't have a pure x32 distro
> Why not?
...
>
> You simply lack a Debian installer/ boot+install medium. Some ports
> architectures to provide netboot images
> 	https://get.debian.org/images/ports/snapshots/2026-06-12/

As I understand, it's a policy in Debian for debian-installer and
the kernel packages to only provide kernels for the native
architecture, i.e. 64-bit x86 kernels are only packaged for
amd64 and not x32 or i686, and 64-bit Arm kernels are only
packaged for arm64 but not armhf or formerly armel.

It would of course be trivial to create a kernel package with a
64-bit kernel inside of an x32/armhf/armel .deb file, but that
would not be included as an official package.

>> always require you to start with a 64-bit installer. [for
>> different reasons though: armhf has an installer but its
>> kernel only works on 32-bit machines; i686 kernels can
>> theoretically run on older 64-bit hardware but Debian
>> no longer provides an installer for it]
>>
>> As far as I understand, the typical use case for debian-x32 is
>> to run just a single performance-critical application, either
>> using "dpkg --add-architecture" or mmdebstrap/schroot. I used
>> to do that for having a faster gcc a decade ago when I was using
>> x86 build machines, though these days that probably fails
>> due to the linker running out of virtual memory in large
>> configurations.
>
> The "problem" with not being part of the main distro ist that you can't
> have the packages say from Trixie and have security updates along with
> it. Instead you always track Sid or don't update.

This is also more a policy problem than a technical one.
Obviously one could build all Trixie (or Forky in the future)
source packages for x32 the same way that debian-ports today
contains Sid packages. I don't know if including those
in debian-ports would fundamentally changes that is run,
or if that just needs someone to do it.

      Arnd

Re: [PATCH v2] x86: Start removing X86_X32_ABI

[Maciej W. Rozycki]

On Wed, 8 Jul 2026, Arnd Bergmann wrote:

> As I understand, it's a policy in Debian for debian-installer and
> the kernel packages to only provide kernels for the native
> architecture, i.e. 64-bit x86 kernels are only packaged for
> amd64 and not x32 or i686, and 64-bit Arm kernels are only
> packaged for arm64 but not armhf or formerly armel.

 Weird, x32 vs x64 for the Intel ISA or say n32 vs n64 for the MIPS ISA 
are psABI variants rather than architectures.  All are native, just using 
different register usage conventions.

 And the kernel is a bare metal application, it has nothing to do with the 
userland as far as the user psABI is concerned.  It could use yet another 
psABI and I suspect this is the case at least for some of the Linux ports 
(`-mregparm=' GCC option comes immediately to mind).  Insisting that the 
same compilation options are used for the kernel as with all the userland 
packages in a distribution seems artificial and unreasonable to me.

 BTW, at least with n32 the MIPS architecture permits CPU implementations 
that only support that psABI and not n64.  Never implemented, I believe, 
but just proves its nativity.

 FWIW,

  Maciej

Re: [PATCH v2] x86: Start removing X86_X32_ABI

[David Laight]

On Wed, 8 Jul 2026 17:27:46 +0100 (BST)
"Maciej W. Rozycki" <macro@orcam.me.uk> wrote:

> On Wed, 8 Jul 2026, Arnd Bergmann wrote:
> 
> > As I understand, it's a policy in Debian for debian-installer and
> > the kernel packages to only provide kernels for the native
> > architecture, i.e. 64-bit x86 kernels are only packaged for
> > amd64 and not x32 or i686, and 64-bit Arm kernels are only
> > packaged for arm64 but not armhf or formerly armel.  
> 
>  Weird, x32 vs x64 for the Intel ISA or say n32 vs n64 for the MIPS ISA 
> are psABI variants rather than architectures.  All are native, just using 
> different register usage conventions.

IIRC n32 just uses the 32bit system calls.
x32 can't do that due to the differing alignment of u64.
So the x86-64 kernel has to have three sets of system call wrappers (etc).

	David

> 
>  And the kernel is a bare metal application, it has nothing to do with the 
> userland as far as the user psABI is concerned.  It could use yet another 
> psABI and I suspect this is the case at least for some of the Linux ports 
> (`-mregparm=' GCC option comes immediately to mind).  Insisting that the 
> same compilation options are used for the kernel as with all the userland 
> packages in a distribution seems artificial and unreasonable to me.
> 
>  BTW, at least with n32 the MIPS architecture permits CPU implementations 
> that only support that psABI and not n64.  Never implemented, I believe, 
> but just proves its nativity.
> 
>  FWIW,
> 
>   Maciej
> 

Re: [PATCH v2] x86: Start removing X86_X32_ABI

[Maciej W. Rozycki]

On Wed, 8 Jul 2026, David Laight wrote:

> >  Weird, x32 vs x64 for the Intel ISA or say n32 vs n64 for the MIPS ISA 
> > are psABI variants rather than architectures.  All are native, just using 
> > different register usage conventions.
> 
> IIRC n32 just uses the 32bit system calls.

 It has its own set, as it's a 64-bit ABI and needs to pass 64-bit data 
accordingly.

> So the x86-64 kernel has to have three sets of system call wrappers (etc).

 Likewise a 64-bit MIPS kernel.  Depending on the configuration chosen it 
may have up to three sets, two 64-bit sets for n32 and n64 psABIs each and 
one 32-bit set for o32 compat psABI.

 I don't know what psABI Debian chose for their 64-bit MIPS ports when 
they were still live, but the default for the GNU toolchain for the Linux 
target has been n32.

  Maciej

Re: [PATCH v2] x86: Start removing X86_X32_ABI

[H. Peter Anvin]

On July 8, 2026 1:26:28 PM PDT, David Laight <david.laight.linux@gmail.com> wrote:
>On Wed, 8 Jul 2026 17:27:46 +0100 (BST)
>"Maciej W. Rozycki" <macro@orcam.me.uk> wrote:
>
>> On Wed, 8 Jul 2026, Arnd Bergmann wrote:
>> 
>> > As I understand, it's a policy in Debian for debian-installer and
>> > the kernel packages to only provide kernels for the native
>> > architecture, i.e. 64-bit x86 kernels are only packaged for
>> > amd64 and not x32 or i686, and 64-bit Arm kernels are only
>> > packaged for arm64 but not armhf or formerly armel.  
>> 
>>  Weird, x32 vs x64 for the Intel ISA or say n32 vs n64 for the MIPS ISA 
>> are psABI variants rather than architectures.  All are native, just using 
>> different register usage conventions.
>
>IIRC n32 just uses the 32bit system calls.
>x32 can't do that due to the differing alignment of u64.
>So the x86-64 kernel has to have three sets of system call wrappers (etc).
>
>	David
>
>> 
>>  And the kernel is a bare metal application, it has nothing to do with the 
>> userland as far as the user psABI is concerned.  It could use yet another 
>> psABI and I suspect this is the case at least for some of the Linux ports 
>> (`-mregparm=' GCC option comes immediately to mind).  Insisting that the 
>> same compilation options are used for the kernel as with all the userland 
>> packages in a distribution seems artificial and unreasonable to me.
>> 
>>  BTW, at least with n32 the MIPS architecture permits CPU implementations 
>> that only support that psABI and not n64.  Never implemented, I believe, 
>> but just proves its nativity.
>> 
>>  FWIW,
>> 
>>   Maciej
>> 
>

A very small number, though. The vast majority are the same as either x64 or i386.