4 ms·

If 86-SX/DX support was dropped in 2012, how is that relevant today? From what I understand, that table shows current or recently supported archs ia32 seems to

If 86-SX/DX support was dropped in 2012, how is that relevant today? From what I understand, that table shows current or recently supported archs ia32 seems to be a a more relevant descrition

wahern 6y ago
Although I realize the table and most of the article is primarily concerned with 32-bit CPUs, it's unfortunate that the article fails to mention 64-bit DEC Alpha, which was the second architecture after i386 supported by Linux. And unlike i386 it's still supported. When the article says > Linux was first written as a desktop system for IBM PC compatibles, and was eventually ported to almost every other desktop platform available in the 1990s, including a lot of the early Unix workstations across all architectures. Because of the juxtaposition with the subsequent platform table, I think a lot of people might be misled into think that both 64-bit CPUs and 64-bit Linux was late to the game. But 64-bit Linux existed as a first-class environment before it supported any other 32-bit architectures like MIPS, PowerPC, or SPARC; before Linux gained any commercial attention (DEC notwithstanding); and AFAIU before there was any kind of serious commitment to syscall ABI stability. GCC supported "long long" on 32-bit architectures since at least 1989, before Linux even existed.[1] I think some Unix environments supported 64-bit off_t on 32-bit architectures before Linux was ever ported to Alpha, and possibly before Linux existed. In any event, using long long for off_t was a done deal by January 1995 at the first Large File Summit (LFS) meeting. The first two slides at https://web.archive.org/web/20000903063117/http://ftp.sas.com/standards/large.file/950105/index.html https://web.archive.org/web/20000903063117/http://ftp.sas.co... suggest using long long for off_t was assumed; the year-long summit was apparently concerned with all the other details. That suggests long long was a relatively well worn and mature type in Unix C environments. Moreover, Linux didn't even get LFS support until several years after the LFS POSIX API was formally published in 1996.[2] It could have implemented a similar solution for time_t and time-related syscalls at the same time it did for off_t and file operations. LFS support has been the default for such a long time even on Linux that today nobody even questions whether 32-bit binaries support 64-bit file operations. Instead Linux apparently waited another 15+ years just to implement that exact solution. In other words, the potential to recognize and address the representation of time_t--and 64-bit types on 32-bit architectures more generally--existed basically from the very beginning of Linux and only grew more pressing and easier to implement, at least in terms of toolchain support, with each subsequent year. That's noteworthy. Not because it proves the Linux developers were mistaken or had the wrong priorities, but because it shows they weren't blindsided by the issue. The history can provide guidance for people to navigate similar dilemmas today, regardless of whether one would have left the issue on the table until later in the day, like Linux did, or chosen to address it earlier on. [1] In 1989 GCC supported long long by calling into a library, similar to what it does for some intrinsics when not natively supported. I'm not sure when GCC began open coding 64-bit operations (i.e. generating inline assembly for all operations on 64-bit types). [2] Not until 2.4.0 judging by http://linuxmafia.com/faq/VALinux-kb/2gb-filesize-limit.html http://linuxmafia.com/faq/VALinux-kb/2gb-filesize-limit.html
- justincormack 6y ago
  The large files transition was quite painful and took a long time, and informed the time offset changes.
- arnd 6y ago
  I tried not to talk too much about 64-bit architectures, but that's a good point. Indeed not just Alpha but also MIPS R4000, UltraSPARC, PA-8000 were already around in the 1990s when the 32-bit kernel support got merged, while ppc64, s390x and TileGX hardware came a little later than the corresponding 32-bit ports. For time_t, I remember it first getting discussed seriously among kernel developers around 2010 as it became clearer that we had misjudged how long 32-bit systems would be around for, how much work it would be to fix it, and how long before 2038 things would fall apart from bugs. Before then, the general thinking was we could either delay dealing with it until the 2030s or 32-bit Linux would just not be there any more. I would consider the LFS transition a user space failure, as glibc never made that the default and Debian still builds some packages with 32-bit off_t to avoid breaking the interface between libraries. As late as 2018, glibc was still merging architecture ports (csky) that default to a 32-bit off_t, despite the kernel having 64-bit off_t since 1994 (linux-1.1.46) before any non-i386 ports were added, and all new architectures in the kernel only supporting 64-bit off_t since 2011.

If 86-SX/DX support was dropped in 2012, how is that relevant today? From what I understand, that table shows current or recently supported archs ia32 seems to be a a more relevant descrition

wahern 6y ago

Although I realize the table and most of the article is primarily concerned with 32-bit CPUs, it's unfortunate that the article fails to mention 64-bit DEC Alpha, which was the second architecture after i386 supported by Linux. And unlike i386 it's still supported. When the article says > Linux was first written as a desktop system for IBM PC compatibles, and was eventually ported to almost every other desktop platform available in the 1990s, including a lot of the early Unix workstations across all architectures. Because of the juxtaposition with the subsequent platform table, I think a lot of people might be misled into think that both 64-bit CPUs and 64-bit Linux was late to the game. But 64-bit Linux existed as a first-class environment before it supported any other 32-bit architectures like MIPS, PowerPC, or SPARC; before Linux gained any commercial attention (DEC notwithstanding); and AFAIU before there was any kind of serious commitment to syscall ABI stability. GCC supported "long long" on 32-bit architectures since at least 1989, before Linux even existed.[1] I think some Unix environments supported 64-bit off_t on 32-bit architectures before Linux was ever ported to Alpha, and possibly before Linux existed. In any event, using long long for off_t was a done deal by January 1995 at the first Large File Summit (LFS) meeting. The first two slides at https://web.archive.org/web/20000903063117/http://ftp.sas.com/standards/large.file/950105/index.html https://web.archive.org/web/20000903063117/http://ftp.sas.co... suggest using long long for off_t was assumed; the year-long summit was apparently concerned with all the other details. That suggests long long was a relatively well worn and mature type in Unix C environments. Moreover, Linux didn't even get LFS support until several years after the LFS POSIX API was formally published in 1996.[2] It could have implemented a similar solution for time_t and time-related syscalls at the same time it did for off_t and file operations. LFS support has been the default for such a long time even on Linux that today nobody even questions whether 32-bit binaries support 64-bit file operations. Instead Linux apparently waited another 15+ years just to implement that exact solution. In other words, the potential to recognize and address the representation of time_t--and 64-bit types on 32-bit architectures more generally--existed basically from the very beginning of Linux and only grew more pressing and easier to implement, at least in terms of toolchain support, with each subsequent year. That's noteworthy. Not because it proves the Linux developers were mistaken or had the wrong priorities, but because it shows they weren't blindsided by the issue. The history can provide guidance for people to navigate similar dilemmas today, regardless of whether one would have left the issue on the table until later in the day, like Linux did, or chosen to address it earlier on. [1] In 1989 GCC supported long long by calling into a library, similar to what it does for some intrinsics when not natively supported. I'm not sure when GCC began open coding 64-bit operations (i.e. generating inline assembly for all operations on 64-bit types). [2] Not until 2.4.0 judging by http://linuxmafia.com/faq/VALinux-kb/2gb-filesize-limit.html http://linuxmafia.com/faq/VALinux-kb/2gb-filesize-limit.html

justincormack 6y ago
The large files transition was quite painful and took a long time, and informed the time offset changes.
arnd 6y ago
I tried not to talk too much about 64-bit architectures, but that's a good point. Indeed not just Alpha but also MIPS R4000, UltraSPARC, PA-8000 were already around in the 1990s when the 32-bit kernel support got merged, while ppc64, s390x and TileGX hardware came a little later than the corresponding 32-bit ports. For time_t, I remember it first getting discussed seriously among kernel developers around 2010 as it became clearer that we had misjudged how long 32-bit systems would be around for, how much work it would be to fix it, and how long before 2038 things would fall apart from bugs. Before then, the general thinking was we could either delay dealing with it until the 2030s or 32-bit Linux would just not be there any more. I would consider the LFS transition a user space failure, as glibc never made that the default and Debian still builds some packages with 32-bit off_t to avoid breaking the interface between libraries. As late as 2018, glibc was still merging architecture ports (csky) that default to a 32-bit off_t, despite the kernel having 64-bit off_t since 1994 (linux-1.1.46) before any non-i386 ports were added, and all new architectures in the kernel only supporting 64-bit off_t since 2011.