On 14.12.18 22:16, Thomas Schöbel-Theuer wrote:
Hi,
> Currently, we have a few thousands of servers relying on 32bit ABIs in> some
> thousands of VMs and/or containers of various types (LXC,
OpenVZ,> etc).
Similar w/ my clients, but in Industrie/Embedded/i4.0 world. We have
thousands of devices
On Wed, Jan 09, 2019 at 01:41:14PM +0100, Florian Weimer wrote:
> * Thomas Schöbel-Theuer:
>
> > 2) please _announce_ _now_ that after the _next_ LTS kernel (whichever
> > you want to declare as such), you will _afterwards_ drop the legacy
> > 32bit support for 64 kernels (I am deliberately using
* Thomas Schöbel-Theuer:
> 2) please _announce_ _now_ that after the _next_ LTS kernel (whichever
> you want to declare as such), you will _afterwards_ drop the legacy
> 32bit support for 64 kernels (I am deliberately using "management
> speak" here).
>
> => result: the industry should have to
> On Dec 14, 2018, at 11:41 PM, Thomas Schoebel-Theuer
> wrote:
>
>> On 12/14/18 22:41, Thomas Schöbel-Theuer wrote:
>>> On 12/14/18 22:24, Andy Lutomirski wrote:
>>>
>>> I'm talking about x32, which is a different beast.
>>>
>>
>> So from my viewpoint the mentioned roadmap / timing
On 12/14/18 22:41, Thomas Schöbel-Theuer wrote:
On 12/14/18 22:24, Andy Lutomirski wrote:
I'm talking about x32, which is a different beast.
So from my viewpoint the mentioned roadmap / timing requirements will
remain the same, whatever you are dropping.
Enterprise-critical use cases
Andy Lutomirski dixit:
>x32 is not this at all. The kernel ABI part of x32 isn't ILP32. It's
>IP32, 32-bit size_t, and *64-bit* long. The core kernel doesn't
Yeah, I was looking at this from userspace PoV, as I said I’m not
a Linux kernel programmer.
In BSD we have register_t which is
On 12/14/18 22:24, Andy Lutomirski wrote:
I should clarify again: I am not suggesting that we drop 32-bit
support in the forseeable future. (Well, I might eventually suggest
that we drop support for 32-bit *hardware* at some point, but not for
32-bit compat software.) Linux's compat code is
On Fri, Dec 14, 2018 at 12:13 PM Linus Torvalds
wrote:
>
> On Fri, Dec 14, 2018 at 10:58 AM Andy Lutomirski wrote:
> >
> > Does anyone know *why* Linux’s x32 has __kernel_long_t defined as long long?
>
> It *needs* to be long long, since the headers are used for builds in
> user mode using
On Fri, Dec 14, 2018 at 1:22 PM Thomas Schöbel-Theuer
wrote:
>
> On 12/11/18 02:23, Andy Lutomirski wrote:
> > I'm seriously considering sending a patch to remove x32 support from
> > upstream Linux.
>
> I am downstream maintainer of several self-patched kernels at 1&1 Ionos.
> The kernels are
On 12/11/18 02:23, Andy Lutomirski wrote:
I'm seriously considering sending a patch to remove x32 support from
upstream Linux.
I am downstream maintainer of several self-patched kernels at 1&1 Ionos.
The kernels are rolled out to several tenthousands of production servers
running in several
On Fri, Dec 14, 2018 at 10:58 AM Andy Lutomirski wrote:
>
> Does anyone know *why* Linux’s x32 has __kernel_long_t defined as long long?
It *needs* to be long long, since the headers are used for builds in
user mode using ILP32.
Since __kernel_long_t is a 64-bit (the _kernel_ is not ILP32), you
My impression is it was mostly a desire to reuse existing x86_64 system calls
as much as possible without modification or additional compat layer work.
The 64-bit time requirement seems to have come from an lkml discussion, which
has quite a bit of interesting background about x32:
> On Dec 14, 2018, at 8:55 AM, Rich Felker wrote:
>
>> On Fri, Dec 14, 2018 at 05:38:33PM +0100, Florian Weimer wrote:
>> * Rich Felker:
>>
>>> This is all useless (and wrong since tv_nsec is required to have type
>>> long as part of C and POSIX, regardless of ILP32-vs-LP64; that's a bug
>>>
On Fri, Dec 14, 2018 at 05:38:33PM +0100, Florian Weimer wrote:
> * Rich Felker:
>
> > This is all useless (and wrong since tv_nsec is required to have type
> > long as part of C and POSIX, regardless of ILP32-vs-LP64; that's a bug
> > in glibc's x32).
>
> We should be able to fix standards if
* Rich Felker:
> This is all useless (and wrong since tv_nsec is required to have type
> long as part of C and POSIX, regardless of ILP32-vs-LP64; that's a bug
> in glibc's x32).
We should be able to fix standards if they prove unworkable in practice.
In my opinion, if standards require complex
On 14/12/2018 17:17, Rich Felker wrote:
> On Fri, Dec 14, 2018 at 03:13:10PM +0100, Bernd Petrovitsch wrote:
[..]
>> FWIW I have
>> snip
>> #if defined __x86_64__
>> # if defined __ILP32__ // x32
>> # define PRI_time_t "lld" // for time_t
>> # define PRI_nsec_t "lld"
On Fri, Dec 14, 2018 at 03:13:10PM +0100, Bernd Petrovitsch wrote:
> On 13/12/2018 17:02, Rich Felker wrote:
> > On Tue, Dec 11, 2018 at 11:29:14AM +0100, John Paul Adrian Glaubitz wrote:
> >> I can't say anything about the syscall interface. However, what I do know
> >> is that the weird
On Fri, Dec 14, 2018 at 12:42:34PM +0100, Florian Weimer wrote:
> * Rich Felker:
>
> > On Thu, Dec 13, 2018 at 05:04:59PM +0100, Florian Weimer wrote:
> >> * Rich Felker:
> >>
> >> >> If the compiler can handle the zeroing, that would be great, though not
> >> >> sure how (some
Am Freitag, 14. Dezember 2018, 15:38:53 CET schrieb David Laight:
> From: Richard Weinberger
> > Sent: 13 December 2018 09:05
> > On Thu, Dec 13, 2018 at 6:03 AM Kevin Easton wrote:
> > >
> > > On Tue, Dec 11, 2018 at 11:29:14AM +0100, John Paul Adrian Glaubitz wrote:
> > > ...
> > > > I can't
From: Richard Weinberger
> Sent: 13 December 2018 09:05
> On Thu, Dec 13, 2018 at 6:03 AM Kevin Easton wrote:
> >
> > On Tue, Dec 11, 2018 at 11:29:14AM +0100, John Paul Adrian Glaubitz wrote:
> > ...
> > > I can't say anything about the syscall interface. However, what I do know
> > > is that
On 13/12/2018 17:02, Rich Felker wrote:
> On Tue, Dec 11, 2018 at 11:29:14AM +0100, John Paul Adrian Glaubitz wrote:
>> I can't say anything about the syscall interface. However, what I do know
>> is that the weird combination of a 32-bit userland with a 64-bit kernel
>> interface is sometimes
* Rich Felker:
> On Thu, Dec 13, 2018 at 05:04:59PM +0100, Florian Weimer wrote:
>> * Rich Felker:
>>
>> >> If the compiler can handle the zeroing, that would be great, though not
>> >> sure how (some __attribute__((zero)) which generates a type constructor
>> >> for such structure; it kind of
Hi.
I reported several significant speedups gained by the x32 ABI
for Scheme-based applications (compiled via a gcc backend), e.g.
https://lists.nongnu.org/archive/html/chicken-users/2015-09/msg0.html
https://www.mail-archive.com/bigloo@inria.fr/msg00427.html
On Thu, 13 Dec 2018, Florian Weimer wrote:
> Similarly, we could have integer types with trap representations.
C++2a will require two's complement representation for integer types, with
no trap representations (other than for bool, where only 0 and 1 are valid
representations). It seems very
On Thu, Dec 13, 2018 at 05:04:59PM +0100, Florian Weimer wrote:
> * Rich Felker:
>
> >> If the compiler can handle the zeroing, that would be great, though not
> >> sure how (some __attribute__((zero)) which generates a type constructor
> >> for such structure; it kind of departs from what the C
I will also complain. I use the 32 bit x86 environment regularly for
testing. I have found several bugs and worked with upstream developers
to create fixes.
The developers never said anything like "this is a waste of time
because it was found on 32 bit". Instead, they were universally
supportive.
On Mon, 2018-12-10 at 17:40 -0800, Linus Torvalds wrote:
> On Mon, Dec 10, 2018 at 5:23 PM Andy Lutomirski
> wrote:
> > I'm seriously considering sending a patch to remove x32 support
> > from
> > upstream Linux. Here are some problems with it:
>
> I talked to Arnd (I think - we were talking
* Rich Felker:
>> If the compiler can handle the zeroing, that would be great, though not
>> sure how (some __attribute__((zero)) which generates a type constructor
>> for such structure; it kind of departs from what the C language offers).
>
> The compiler fundamentally can't. At the very least
On Tue, Dec 11, 2018 at 11:29:14AM +0100, John Paul Adrian Glaubitz wrote:
> I can't say anything about the syscall interface. However, what I do know
> is that the weird combination of a 32-bit userland with a 64-bit kernel
> interface is sometimes causing issues. For example, application code
On Thu, Dec 13, 2018 at 12:40:25PM +, Catalin Marinas wrote:
> On Wed, Dec 12, 2018 at 10:03:30AM -0800, Andy Lutomirski wrote:
> > On Wed, Dec 12, 2018 at 8:52 AM Rich Felker wrote:
> > > On Wed, Dec 12, 2018 at 08:39:53AM -0800, Andy Lutomirski wrote:
> > > > I'm proposing another
On Thu, Dec 13, 2018 at 9:39 AM Olof Johansson wrote:
>
> On Tue, Dec 11, 2018 at 9:40 AM Linus Torvalds
> wrote:
> >
> > On Mon, Dec 10, 2018 at 5:23 PM Andy Lutomirski wrote:
> > >
> > > I'm seriously considering sending a patch to remove x32 support from
> > > upstream Linux. Here are some
On Tue, Dec 11, 2018 at 9:40 AM Linus Torvalds
wrote:
>
> On Mon, Dec 10, 2018 at 5:23 PM Andy Lutomirski wrote:
> >
> > I'm seriously considering sending a patch to remove x32 support from
> > upstream Linux. Here are some problems with it:
>
> I talked to Arnd (I think - we were talking about
On Wed, Dec 12, 2018 at 10:03:30AM -0800, Andy Lutomirski wrote:
> On Wed, Dec 12, 2018 at 8:52 AM Rich Felker wrote:
> > On Wed, Dec 12, 2018 at 08:39:53AM -0800, Andy Lutomirski wrote:
> > > I'm proposing another alternative. Given that x32 already proves that
> > > the user bitness model
On Thu, Dec 13, 2018 at 10:05:14AM +0100, Richard Weinberger wrote:
> On Thu, Dec 13, 2018 at 6:03 AM Kevin Easton wrote:
> >
> > On Tue, Dec 11, 2018 at 11:29:14AM +0100, John Paul Adrian Glaubitz wrote:
> > ...
> > > I can't say anything about the syscall interface. However, what I do know
> >
On Thu, Dec 13, 2018 at 10:37:31AM +0100, Sven Hartrumpf wrote:
> Will the proposed patch ("only") remove the possibility to build x32 kernels
> or will it make impossible to compile and run any x32 binaries?
There's no such thing as x32 kernels. It's an ABI atop amd64 kernels; the
kernel is
Will the proposed patch ("only") remove the possibility to build x32 kernels
or will it make impossible to compile and run any x32 binaries?
Sven
On Thu, Dec 13, 2018 at 6:03 AM Kevin Easton wrote:
>
> On Tue, Dec 11, 2018 at 11:29:14AM +0100, John Paul Adrian Glaubitz wrote:
> ...
> > I can't say anything about the syscall interface. However, what I do know
> > is that the weird combination of a 32-bit userland with a 64-bit kernel
> >
On Tue, Dec 11, 2018 at 11:29:14AM +0100, John Paul Adrian Glaubitz wrote:
...
> I can't say anything about the syscall interface. However, what I do know
> is that the weird combination of a 32-bit userland with a 64-bit kernel
> interface is sometimes causing issues. For example, application
My main reason on staying at Pentium 4 is that it does not contain
Intel ME backdoor (it came starting with Core 2 Duo)
ср, 12 дек. 2018 г. в 22:12, Andy Lutomirski :
>
> On Wed, Dec 12, 2018 at 10:50 AM Ivan Ivanov wrote:
> >
> > Please don't drop x86 support from the Linux kernel ! You may not
On Wed, Dec 12, 2018 at 10:50 AM Ivan Ivanov wrote:
>
> Please don't drop x86 support from the Linux kernel ! You may not
> realize it, but there are plenty of people who care about x86 systems.
> I have a good old Pentium 4 based computer which is 32-bit, using it
> for some weird Linux
Please don't drop x86 support from the Linux kernel ! You may not
realize it, but there are plenty of people who care about x86 systems.
I have a good old Pentium 4 based computer which is 32-bit, using it
for some weird Linux experiments + retro gaming, and if I can't run
new Linux kernels there
On Wed, 12 Dec 2018, Arnd Bergmann wrote:
> > MIPS had o32, n32, n64 since like forever.
>
> o32 and n32 are practically the same, the only difference on the
> syscall ABI that I can see are the actual syscall numbers, and
> the 'struct sigcontext' definition.
And for syscalls that have 64-bit
On Wed, Dec 12, 2018 at 8:52 AM Rich Felker wrote:
>
> On Wed, Dec 12, 2018 at 08:39:53AM -0800, Andy Lutomirski wrote:
> > > On Dec 11, 2018, at 6:33 PM, Thorsten Glaser wrote:
> > >
> > > Andy Lutomirski dixit:
> > >
> >
> > >
> > >> IMO the real right solution would be to push the whole
On Wed, Dec 12, 2018 at 08:39:53AM -0800, Andy Lutomirski wrote:
> > On Dec 11, 2018, at 6:33 PM, Thorsten Glaser wrote:
> >
> > Andy Lutomirski dixit:
> >
>
> >
> >> IMO the real right solution would be to push the whole problem to
> >> userspace: get an ILP32 system working with almost or
> On Dec 11, 2018, at 6:33 PM, Thorsten Glaser wrote:
>
> Andy Lutomirski dixit:
>
>
>> IMO the real right solution would be to push the whole problem to
>> userspace: get an ILP32 system working with almost or entirely LP64
>
> Is this a reflex of Linux kernel developers? ;-)
>
> I doubt that
On Wed, Dec 12, 2018 at 02:46:00PM +, Steven Newbury wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Wed, 2018-12-12 at 09:01 -0500, Rich Felker wrote:
> > On Wed, Dec 12, 2018 at 09:12:34AM +, Steven Newbury wrote:
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Wed, 2018-12-12 at 09:01 -0500, Rich Felker wrote:
> On Wed, Dec 12, 2018 at 09:12:34AM +, Steven Newbury wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > First off I'd like to request: Please don't break my userspace!
On Wed, Dec 12, 2018 at 09:12:34AM +, Steven Newbury wrote:
> -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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Wed, 2018-12-12 at 10:48 +, Thorsten Glaser wrote:
> Steven Newbury dixit:
>
> >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
>
> Do you mean
Steven Newbury dixit:
>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
Do you mean i386?
x86 = { i386, x32, amd64 }
No, please don’t. I use i386 as “companion architecture” to x32,
only the kernel and
-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.
On Wed, Dec 12, 2018 at 3:38 AM Thorsten Glaser wrote:
>
> Andy Lutomirski dixit:
>
> >That’s the thing, though: the whole generic kernel compat
> >infrastructure assumes there are at most two ABIs: native and, if
> >enabled and relevant, compat. x32 breaks this entirely.
>
> MIPS had o32, n32,
Andy Lutomirski dixit:
>That’s the thing, though: the whole generic kernel compat
>infrastructure assumes there are at most two ABIs: native and, if
>enabled and relevant, compat. x32 breaks this entirely.
MIPS had o32, n32, n64 since like forever.
ARM has old ABI, EABI and now 64-bit.
Other
> On Dec 11, 2018, at 3:35 PM, Thorsten Glaser wrote:
>
> Andy Lutomirski dixit:
>
>> What happens if someone adds a struct like:
>>
>> struct nasty_on_x32 {
>> __kernel_long_t a;
>> void * __user b;
>> };
>>
>> On x86_64, that's two 8-byte fields. On x86_32, it's two four-byte
>> fields. On
On Tue, 11 Dec 2018, Shawn Rutledge wrote:
> I like the idea of x32 in theory: any machine with 4GB or less of memory
> for sure does not really need to waste any precious space storing 64-bit
> pointers; and even if more memory is available, software that needs to
> access more than 4GB per
On Wed, Dec 12, 2018 at 12:38 AM Thorsten Glaser wrote:
>
> Andy Lutomirski dixit:
>
> >What happens if someone adds a struct like:
> >
> >struct nasty_on_x32 {
> > __kernel_long_t a;
> > void * __user b;
> >};
> >
> >On x86_64, that's two 8-byte fields. On x86_32, it's two four-byte
>
On Tue, 11 Dec 2018, Thorsten Glaser wrote:
> Furthermore, x32 was the first of the many *64ilp32
> architectures; I know I’ve seen amd64ilp32 and at least
> one other I don’t recall.
Maybe you mean n32 MIPS, complete kernel+userland support for which has
been available in Linux from 2001?
Andy Lutomirski dixit:
>What happens if someone adds a struct like:
>
>struct nasty_on_x32 {
> __kernel_long_t a;
> void * __user b;
>};
>
>On x86_64, that's two 8-byte fields. On x86_32, it's two four-byte
>fields. On x32, it's an 8-byte field and a 4-byte field. Now what?
Yes, that’s
On Tue, Dec 11, 2018 at 03:22:43PM -0800, Andy Lutomirski wrote:
> On Tue, Dec 11, 2018 at 2:14 PM Thorsten Glaser wrote:
> > I was also considering investing a nontrivial amount of
> > work into porting klibc to x32, since hpa does not wish
> > to do it himself. Thankfully I have only done a bit
On Tue, Dec 11, 2018 at 09:59:48PM +, Thorsten Glaser wrote:
> John Paul Adrian Glaubitz dixit:
>
> >I can't say anything about the syscall interface. However, what I do know
> >is that the weird combination of a 32-bit userland with a 64-bit kernel
> >interface is sometimes causing issues.
On Tue, Dec 11, 2018 at 2:14 PM Thorsten Glaser wrote:
>
> Note: please keep me in Cc because I am not subscribed.
>
> Linus Torvalds dixit:
>
> >I'm not opposed to trying to sunset the support, but let's see who
> >complains..
>
> I will hereby complain.
>
> I’m using Debian/x32 on my main
John Paul Adrian Glaubitz dixit:
>I can't say anything about the syscall interface. However, what I do know
>is that the weird combination of a 32-bit userland with a 64-bit kernel
>interface is sometimes causing issues. For example, application code usually
Yes, but more and more ${foo}64ilp32
Note: please keep me in Cc because I am not subscribed.
Linus Torvalds dixit:
>I'm not opposed to trying to sunset the support, but let's see who complains..
I will hereby complain.
I’m using Debian/x32 on my main desktop at work, and do
occasionally help out with porting issues. It’s a good
I like the idea of x32 in theory: any machine with 4GB or less of memory
for sure does not really need to waste any precious space storing 64-bit
pointers; and even if more memory is available, software that needs to
access more than 4GB per process is somewhat rare (as it should be). I
used a
On Tue, Dec 11, 2018 at 12:37:42PM +0100, Florian Weimer wrote:
> * Catalin Marinas:
> > On Tue, Dec 11, 2018 at 10:02:45AM +0100, Arnd Bergmann wrote:
> >> On Tue, Dec 11, 2018 at 6:35 AM Andy Lutomirski wrote:
> >> > I tried to understand what's going on. As far as I can tell, most of
> >> >
* Catalin Marinas:
> On Tue, Dec 11, 2018 at 10:02:45AM +0100, Arnd Bergmann wrote:
>> On Tue, Dec 11, 2018 at 6:35 AM Andy Lutomirski wrote:
>> > I tried to understand what's going on. As far as I can tell, most of
>> > the magic is the fact that __kernel_long_t and __kernel_ulong_t are
>> >
On Tue, Dec 11, 2018 at 10:02:45AM +0100, Arnd Bergmann wrote:
> On Tue, Dec 11, 2018 at 6:35 AM Andy Lutomirski wrote:
> > I tried to understand what's going on. As far as I can tell, most of
> > the magic is the fact that __kernel_long_t and __kernel_ulong_t are
> > 64-bit as seen by x32 user
On 12/11/18 11:37 AM, Florian Weimer wrote:
> Note that OpenJDK (well, Hotspot) has its own 32-bit pointer support for
> the Java heap (compressed oops), so only the native code parts (and JNI)
> benefit from x32 anyway.
Yeah, I was actually only talking about this single commit by me to add
Zero
* John Paul Adrian Glaubitz:
> As for the enterprise support, this seems to be correct. I don't know
> of any enterprise distribution with x32 support either.
Me neither. I would expect a pure userspace port, with limitations in
what ioctls you can use, and perhaps support from GCC to share
Hello!
I'm Debian's principal maintainer of the x32 port.
On 12/11/18 2:23 AM, Andy Lutomirski wrote:
> 1. It's not entirely clear that it has users. As far as I know, it's
> supported on Gentoo and Debian, and the Debian popcon graph for x32
> has been falling off dramatically. I don't think
On Tue, Dec 11, 2018 at 6:35 AM Andy Lutomirski wrote:
> On Mon, Dec 10, 2018 at 7:15 PM H.J. Lu wrote:
> > On Mon, Dec 10, 2018 at 5:23 PM Andy Lutomirski wrote:
> Right. My question wasn't whether x32 had developers -- it was
> whether it had users. If the only users are a small handful of
* Linus Torvalds:
> Apparently the main real use case is for extreme benchmarking. It's
> the only use-case where the complexity of maintaining a whole
> development environment and distro is worth it, it seems. Apparently a
> number of Spec submissions have been done with the x32 model.
Are you
On Mon, Dec 10, 2018 at 05:23:39PM -0800, Andy Lutomirski wrote:
> Hi all-
>
> I'm seriously considering sending a patch to remove x32 support from
> upstream Linux. Here are some problems with it:
>
> 1. It's not entirely clear that it has users. As far as I know, it's
> supported on Gentoo
On Mon, Dec 10, 2018 at 7:15 PM H.J. Lu wrote:
>
> On Mon, Dec 10, 2018 at 5:23 PM Andy Lutomirski wrote:
> >
> > Hi all-
> >
> > I'm seriously considering sending a patch to remove x32 support from
> > upstream Linux. Here are some problems with it:
> >
> > 1. It's not entirely clear that it
On Mon, Dec 10, 2018 at 5:23 PM Andy Lutomirski wrote:
>
> Hi all-
>
> I'm seriously considering sending a patch to remove x32 support from
> upstream Linux. Here are some problems with it:
>
> 1. It's not entirely clear that it has users. As far as I know, it's
> supported on Gentoo and
On December 10, 2018 5:40:33 PM PST, Linus Torvalds
wrote:
>On Mon, Dec 10, 2018 at 5:23 PM Andy Lutomirski
>wrote:
>>
>> I'm seriously considering sending a patch to remove x32 support from
>> upstream Linux. Here are some problems with it:
>
>I talked to Arnd (I think - we were talking about
On Mon, Dec 10, 2018 at 5:23 PM Andy Lutomirski wrote:
>
> I'm seriously considering sending a patch to remove x32 support from
> upstream Linux. Here are some problems with it:
I talked to Arnd (I think - we were talking about all the crazy ABI's,
but maybe it was with somebody else) about
Hi all-
I'm seriously considering sending a patch to remove x32 support from
upstream Linux. Here are some problems with it:
1. It's not entirely clear that it has users. As far as I know, it's
supported on Gentoo and Debian, and the Debian popcon graph for x32
has been falling off
78 matches
Mail list logo
