From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2FA2E3D9684 for ; Thu, 4 Jun 2026 20:27:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780604853; cv=none; b=RGLnPWyXbU57pJfGDNRPO1cSh/ahgJEu637RnyiSj90NeVq5oPk0bM8h15ZLKCdeFvIZc8uyw2jE7gdhkvNAP+cfrIcDTzKNVAS1LWlca1XkDe8nm9ZB2OSC5RJOg41CfBtGUXcQ91p1b3MI9bIHeNmiGCziW4K0+YDwVfhqq4g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780604853; c=relaxed/simple; bh=MFlxjvc1Hq/NGL6s+xbxd34g66erNxodFoffwit0vJ8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=kJ7jn3FUlXV9+mHkF3UQ7NKckwTmyPAfT1rTG/Eo/RuiEXosXffoHiT+ByTClajI01SkuNVDoMdFHPolgWhjSyIfGaiYXUlBlo4a5KBAaoEeWyc0zolRszgyaXUJMlR8o+NF7XHvzkQy31dnklj4HyHR2jdVcifAvP4hbB43gf8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TRHjHcm3; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TRHjHcm3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 24C8A1F00893; Thu, 4 Jun 2026 20:27:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780604852; bh=XhfOOC+ISsszj1S0TijsRs5+C7wuglRwktLkm2KP570=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=TRHjHcm3sSF2UP2nOls9s+e2akN/4sqz+kaIxmKeHEC3jL3RE3XTXJlLkJ7p+MFv/ iotE9ad8CO5GOgvbQnPY/nGzGnTPD/95fcrf5VIe5NaCkwCHWARX2eOYqIVqrJCz6T 9SnD2DBL614C63/lsvRFwaS13nE246vWoZaZ/dzIUXssSC5+X665DvmIC4l9QBronq lhdRLQAR/I/yhWpXhEulv1LrUB2HnEkX6WzwqTpaBmcrWxLWg/g/jh0Cj+gm9NUHzF AOwPL7u8el5udJoWXRvo9AZY5exiUpxEmIe9OkKuUUaZpo0oVyVK/mmKOgj4PLUni8 9rQL6eQU5AucQ== From: Thomas Gleixner To: "H. Peter Anvin" , Sebastian Andrzej Siewior , linux-kernel@vger.kernel.org, x86@kernel.org Cc: Borislav Petkov , Dave Hansen , Ingo Molnar , Jonathan Corbet Subject: Re: [PATCH] x86: Start removing X86_X32_ABI In-Reply-To: <10BF3F18-4709-43D6-979C-49067707F1C1@zytor.com> References: <20260523093734.A3AR7reJ@linutronix.de> <10BF3F18-4709-43D6-979C-49067707F1C1@zytor.com> Date: Thu, 04 Jun 2026 22:27:28 +0200 Message-ID: <87o6hq3vbj.ffs@fw13> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Sat, May 23 2026 at 14:43, H. Peter Anvin wrote: > On May 23, 2026 2:37:34 AM PDT, Sebastian Andrzej Siewior wrote: >>- >> config COMPAT_32 >> def_bool y >> depends on IA32_EMULATION || X86_32 > > So I'm not opposed to sunsetting x32; it happened too late to actually > be able to become useful (sorry, Knuth.) I doubt it was ever useful, but that's a different debate to be had. > However, we can not recycle the syscall numbers. The x32 flag in the > syscall number was advisory originally; it was introduced late in the > game to work around a design bug in the input subsystem (*). Correct. That's unfortunate and basically forces us to skip the arbitrary x32 range for all architectures if we want to keep the syscall numbers in sync. But aside of that x32 is just another maintenance burden for no value. Please let us get rid of it and document that the syscall number space is poisened forever. Thanks, tglx