Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lots of bugs in 32-bit x86 Linux entry code

lwn.net

Post reply on HN
Print view View original

41–50 of 110 posts

Re: Lots of bugs in 32-bit x86 Linux entry code

#41

Post by wahern »

jdsully wrote: post #30
gdxhyrd wrote: post #28

Earlier quoted context omitted.

Worthwhile? We had PAE for a long time, sure, but I think it was fairly obvious when the Athlon 64 appeared that 4GB was not going to cut it, given some people already had 1GB at home...

At the time 1GB was a ton of memory and few applications would use anywhere near that. A 64-bit kernel took on fairly quickly but actually compiling 64-bit applications took a lot longer. Consensus at the time was the memory overhead of larger pointers outweighed the benefits of extra registers.

> Consensus at the time

I wouldn't call it consensus, just a persistent claim by a large fraction of developers. They finally got to prove their claims with x32 ABI, which was ILP32 in amd64 mode, including the additional registers. Few if any people used it, nor did it show better performance in practice.

Regarding 64-bit support: by the time amd64 chips shipped people had been writing software for the 64-bit Alpha for 10 years, and 7 years for sparc64. IME most open source software was already 64-bit clean and worked well out-of-the-box. Back then the open source community, and especially GNU projects, heavily emphasized platform and hardware portability.

Perhaps the situation on Windows was different. It also didn't help that Windows kept long 32 bits, which had the effect of breaking code that cast between pointers and long (intptr_t didn't come until C99). The 64-bit ABI for all Unix platforms (AFAIU) carried forward the relationship between long and pointer. I don't think I ever recall seeing Unix or open source code casting a pointer type to int, only long; it was Windows software that presumed pointer->int conversions worked.

Re: Lots of bugs in 32-bit x86 Linux entry code

#42

Post by heavyset_go »

gdxhyrd wrote: post #25
heavyset_go wrote: post #4

Earlier quoted context omitted.

There were 32-bit netbooks being sold the last time I looked in 2015.

Sure, but the ones that pay the bills are servers and companies which don't care one bit about i386.

Agreed, however open source has always relied on enthusiasts for consumer-grade hardware support.

Re: Lots of bugs in 32-bit x86 Linux entry code

#43

Post by saagarjha »

derefr wrote: post #39
srgpqt wrote: post #37

Earlier quoted context omitted.

1GB is still a lot of memory. If anything, we've only learned to squander all available memory.

Go ahead and buffer 4k video streams to disk, I dare you :) There's a reason that even modern appliance platforms like Apple/Android TV need multiple GBs of memory, and it ain't bloat.

I wouldn’t be so sure.

Re: Lots of bugs in 32-bit x86 Linux entry code

#44

Post by makomk »

heavyset_go wrote: post #4
human_banana wrote: post #3

Maybe because nobody uses 32-bit x86 anymore?

There were 32-bit netbooks being sold the last time I looked in 2015.

Unfortunately, upstream doesn't really notice if 32-bit x86 breaks. This isn't just a kernel problem; glibc managed to push out a release back in 2017 that broke memchr on 32-bit Atom in a way that tended to cause programs calling it to segfault. It turns out that amongst a few other things, including Python, the glibc build process itself relies on memchr working... I don't think they actually tested the code path in question after modifying it.

Re: Lots of bugs in 32-bit x86 Linux entry code

#45

Post by heavyset_go »

opencl wrote: post #33
heavyset_go wrote: post #4

Earlier quoted context omitted.

There were 32-bit netbooks being sold the last time I looked in 2015.

The really fun part was when they launched the first 64 bit Atom CPUs (Bay Trail) and then a bunch of them got shipped with only 32 bit UEFI and cannot boot in 64 bit mode.

Early 64-bit Intel Macs also shipped with a 32-bit UEFI limitation, but they were able to boot into a 64-bit system.

Re: Lots of bugs in 32-bit x86 Linux entry code

#47

Post by kbenson »

cptskippy wrote: post #16
jdsully wrote: post #5

I remember being an early adopter of 64-bit Linux with my Athlon64 back in the day. Lots of stuff was broken and I got a lot of debate on whether it was any faster or worthwhile at all. It's really cool to see the technology curve go full circle.

Completely off topic but... Althlon64 was a swift kick in the nuts for Intel, but AMD really didn't followup until Ryzen. I wonder if they're going to stick around and fight this time.

Sometimes when the swift kick in the nuts is delivered to an 800-pound gorilla, it doesn't matter if you stay around to fight, you're outclassed.

This time, AMD may have stepped up with a steel pipe. We'll see how well they can use it...

Re: Lots of bugs in 32-bit x86 Linux entry code

#48

Post by nickysielicki »

jdsully wrote: post #5

I remember being an early adopter of 64-bit Linux with my Athlon64 back in the day. Lots of stuff was broken and I got a lot of debate on whether it was any faster or worthwhile at all. It's really cool to see the technology curve go full circle.

My dad bought me an Anthlon64 machine for Christmas and we put it together. Not know much about anything, I remember being pissed off/confused that I didn’t have Windows XP 64-bit in spite of having that Anthlon64 sticker on the front.

A few years later my brother was starting a web server to host a forum for the Digital TV switch-over focused on the Madison, WI market, shout-out and RIP madcityhd.com

Watching him setup Fedora on the box on the floor of his bedroom and using Compiz wobbly-windows was enough to hook me. I stole his install CD and nuked my drive (much to the irritation of my dad, who knew that I would be stealing one of his nights to reinstall Windows when I eventually realized could no longer play counter-strike), It was fun to see it come full-circle a year or two after I was ticked-off about my Anthlon64 not running a 64 bit operating system, when I started trying other distos and realized, “Hey, I can actually use the 64 bit one now!”

Fun times. I wonder how many kids got hooked on Linux by wobbly windows. I know that’s what brought me in, haha.

Re: Lots of bugs in 32-bit x86 Linux entry code

#49

Post by tyingq »

cptskippy wrote: post #16
jdsully wrote: post #5

I remember being an early adopter of 64-bit Linux with my Athlon64 back in the day. Lots of stuff was broken and I got a lot of debate on whether it was any faster or worthwhile at all. It's really cool to see the technology curve go full circle.

Completely off topic but... Althlon64 was a swift kick in the nuts for Intel, but AMD really didn't followup until Ryzen. I wonder if they're going to stick around and fight this time.

Back then, AMD kind of had to license the x64 stuff to Intel for cross license reasons. They aren't under any pressure this time to give away anything.

Re: Lots of bugs in 32-bit x86 Linux entry code

#50

Post by xelxebar »

acqq wrote: post #34
bryanlarsen wrote: post #6

Earlier quoted context omitted.

No, that's the i386 architecture, which is still well supported AFAICT. x86_32 is a funny architecture that requires 64 bit chips but uses 32 bit pointers. http://www.h-online.com/open/features/Kernel-Log-x32-ABI-get...

No, see the source from Linux kernel: https://github.com/torvalds/linux/blob/master/arch/x86/Kconf... For all x86 processors, now there is a name "X86_32" which "depends on !64BIT" (i.e. 64BIT flag has to be off). and there is a name "X86_64" which "depends on 64BIT" (i.e. 64BIT flag being on). Under new convention X86 is a common prefix for both 32 and 64-bit kernels for x86 processors, and the suffix _32 means the…

Beatuiful, high-value reply. Thank you for making the connection to upstream and unpacking things with good, concise exposition.
Post reply on HN