Re: Can we drop upstream Linux x32 support?

[Steven Newbury]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

First off I'd like to request: Please don't break my userspace!

I have a number of systems running with x32-abi as native.  They work
well, I've no want or desire to upgrade their memory or CPUs to make
keep them working as well as they do now.  Let alone the hassle of
having to redeploy with a completely different ABI.


I've been working on getting as much userspace as I can working with
x32 since it first became somewhat usable, I've sent patches upstream
and pushed to encourage projects to write portable code.  Sometimes
that has meant just little tweaks to build systems, or sometimes
disabling asm where I consider it isn't worth the effort of making it
work.  For other projects I've converted the asm or even in some cases
got the JIT working, mozjs17 for example.

So I'm both a user and a developer.

Breaking support for x32 would be really bad for me, but if I'm the
only one using it I suppose I can't really justify it being kept on
that basis.  I know CERN has sucessfully experimented with it over the
years though, so I wouldn't be surprised if there are other users
hiding out there.

I can't help but wonder if it wouldn't make more sense to drop x86
support from long mode than x32.  AMD64 x86 support was always intended
 as a compatibility feature, I very much doubt there are more people
out there using an x86 native userspace on a 64 bit kernel than there
are native x32 users.  x86 support could be implemented via KVM and/or
qemu-user.  There is no reason to keep the extra complexity in the
kernel for what is effectively an emulation layer anyway.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEWa1B4K0Hk12RDstE+lAa6BzrmeAFAlwQ0QQACgkQ+lAa6Bzr
meBILQf9EF1GqHKfnRC7AOFnNCm0235OmH1dJJd4+6zzLWTKGAAvFF6T1F1IG3fu
QTZTEok5s238BapjrvgZ5bxtMP0TGNK++vGZ8ESb6Hi+Q975duemWD8ZsSVPw7SH
YcqEgmxKn28iHq/W//SUPo1kqz7D0jFCDU9dIA1wQY+AwTIzjfMPltWGrKbMbOBQ
LsW+VlL7PfoEzx9sXvaMpjgINEouCvLcuTvhTRclCOO5MWqTQLdIdL9urrBGukUN
7dvKiWWAk6c/Af1W5jnLtYIijaztu3hrZ7lykFmOnwyDoeOhqzIhUkcDaLJcy7Vo
Rsrb1CjzFngpbgTJeOkyC9ZGZ2CZ0g==
=TCpw
-----END PGP SIGNATURE-----