On Mon, 2024-08-19 at 11:46 -0700, Maciej Żenczykowski wrote: > On Mon, Aug 19, 2024 at 5:23 AM Johannes Berg <johan...@sipsolutions.net> > wrote: > > > > On Tue, 2024-08-13 at 16:47 -0700, Maciej Żenczykowski wrote: > > > Without this patch: > > > #!/usr/bin/python3 > > > import ctypes > > > import os > > > personality = ctypes.CDLL(None).personality > > > personality.restype = ctypes.c_int > > > personality.argtypes = [ctypes.c_ulong] > > > PER_LINUX32=8 > > > personality(PER_LINUX32) > > > print(os.uname().machine) > > > returns: > > > x86_64 > > > instead of the desired: > > > i686 > > > > > > > But ... why should it work? UML has no 32-bit compat support anyway. > > Well, that's certainly a fair point. > On 'native' x86_64 this works even for 64-bit processes though. > I wonder if that, in itself, is a feature or a bug... > > In my case I was writing some debug code (to print the environment > some test code is running in, since I think it was failing due to > running 32-bit code in PER_LINUX32 on 64-bit arm) and testing (the > test code) on x86_64 UML. I was surprised to discover the difference > in UML vs my host desktop. >
Alright, I have no idea. This doesn't really seem to do anything else, so I'm not sure what the point is... It _was_ introduced for compat though, but obviously the binary doesn't suddenly change to a 32-bit binary when you do this :) Maybe the x86 maintainers have any other comments? johannes
