Linux Kernel Developers Discuss Dropping x32 Support (phoronix.com)
An anonymous reader shared a report: It was just several years ago that the open-source ecosystem began supporting the x32 ABI, but already kernel developers are talking of potentially deprecating the support and for it to be ultimately removed..
[...] While the x32 support was plumbed through the Linux landscape, it really hasn't been used much. Kernel developers are now discussing the future of the x32 ABI due to the maintenance cost involved in still supporting this code but with minimal users. Linus Torvalds is in favor of sunsetting x32 and many other upstream contributors in favor of seeing it deprecated and removed.
[...] While the x32 support was plumbed through the Linux landscape, it really hasn't been used much. Kernel developers are now discussing the future of the x32 ABI due to the maintenance cost involved in still supporting this code but with minimal users. Linus Torvalds is in favor of sunsetting x32 and many other upstream contributors in favor of seeing it deprecated and removed.
Would it have hurt to include this?
The Linux x32 ABI as a reminder requires x86_64 processors and is engineered to support the modern x86_64 features but with using 32-bit pointers rather than 64-bit pointers. The x32 ABI allows for making use of the additional registers and other features of x86_64 but with just 32-bit pointers in order to provide faster performance when 64-bit pointers are unnecessary.
...except for the fact that this explanation is 25% of the four-paragraph article, and another 25% of it was already in TFS. Oops.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
That's not what the x32 ABI is for.
That's not what x32 is. 32-bit x86 will still be supported.
"x32" is an ABI for x86-64 that uses 32-bit pointers with the x86-64 instruction set for better performance when a large address space is not needed. ;)
It's in the second paragraph in the TFA
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
Wrong CPU, nothing to do with 4/586s. From TFA itself:
The Linux x32 ABI as a reminder requires x86_64 processors and is engineered to support the modern x86_64 features but with using 32-bit pointers rather than 64-bit pointers. The x32 ABI allows for making use of the additional registers and other features of x86_64 but with just 32-bit pointers in order to provide faster performance when 64-bit pointers are unnecessary.
While the x32 support was plumbed through the Linux landscape, it really hasn't been used much. Kernel developers are now discussing the future of the x32 ABI due to the maintenance cost involved in still supporting this code but with minimal users.
Wikipedia:
It's a 64-bit CPU thing, not a 32-bit CPU thing.
This isn't about removing x86 32 bit support as far as I can see, it's about removing 32 bit support for 64-bit processors using the x86_64 branch, it's niche and only started appearing in 2012:
details
You mean "x86" architecture, and that's not what this is about. "x32" is a feature of the Linux kernel where an application can run in a 4GB address space with all pointers being only 32 bit wide while still being in x86-64 mode and having access to all of the new instructions.
Does anyone have comments on how many apps made use of this? I know that's kind of nebulous, and a nebulous answer is fine.
Comment removed based on user account deletion
A 486 does not support x32.
No, not at all. The two have nothing to do with each other. x32 is not the same as x86.
It allows access to the extended registers of x86_64 but with 32-bit pointers. It requires an x86_64 processor to be used.
http://bfy.tw/IIU
Sig?
Perhaps you could not be retarded and just know this?
X32 is a stupid version of 64 bit that uses 32-bit pointers.
Never understood who thought this was a good idea.
People who care about memory footprint? Linux is used in some pretty small systems, still. If you have far, far less than 4GB you not only don't need 64-bit addressing, you need to not waste 4 bytes on every pointer.
Why not just use x86? More registers (and x64 has a lot more registers) can make a real performance impact.
Socialism: a lie told by totalitarians and believed by fools.
Several refers to a small count of some group of items. "Few" is a similar word. "Several years" could refer to anything from 2-10 years in conversation. It does not imply less or more than something else. You could say "it took several years more than expected" if you are referring to something taking a longer time. But, it is still referring to a small quantity of years. You could also say it took several years less than expected" if it happened faster than the estimated amount of time.
One reason Linux has supported so many processors is that most of it has always been in written in C.
It looks like you missed a verb there. Either that, or Slashdot has finally come across something everyone on Slashdot can agree is "News for Nerds." One nerd attempting to assassinate a group of nerds certainly meets every possible meaning of "News for Nerds."
How many people use it? 50? 500? I see no reason for it to exist. It's not like Open Source has too much manpower to afford supporting a queer architecture barely used by anyone.
"One" is 1 .25% - .50%
"A couple" is 2
"A few" is 3 or 4 (in some cases, 5)
"Several" is 5 6 7 8 or 9
"A bunch" is the normal amount of something plus an additional
"A lot" is the normal amount of something x2
"A shitload" is the normal amount of something x10
"A fuckload" is the normal amount of something x10 and you're drunk.
Politics; n. : A religion whereby man is god.
Woops, "A bunch" is the normal amount of something plus an additional 25% - 50%
Politics; n. : A religion whereby man is god.
Not to mention that x32 still lets you use 64-bit native words, etc. for faster computation with the smaller memory footprint.
Can you relate that in the standard slashdot unit of measure, the Library of Congress (LOC)? :)
Well, there's spam egg sausage and spam, that's not got much spam in it.
How else will I run Linux on my SEGA Genesis?
Oh wait, x32, not 32X.
Carry on.
#DeleteFacebook
Also PC-relative addressing works in x32 mode, and that's a huge gain over i386 for position-independent code (think shared libraries and ASLR). It's supposed to help reduce the size of the working set so you don't thrash the cache as much as you would with 64-bit pointer, size_t etc. Cache miss latency is horrible on modern systems. The trouble is, there are very few libraries built for it, so you pretty much have to build your own userland before you can do anything.
Is surely to provide a better abstraction layer.
I should not have to care if x32, DEC or the Prime Radiant are supported by the kernel admins. Patches should largely just work with minimal hacking.
In turn, it should not be such hard work to maintain code. Different systems have different ways to achieve the same thing with different optimizations possible.
All of that can be stuck in helper code, well almost all, which means there is far less maintenance.
This is not esoteric wisdom, its the basis behind all abstraction layers and the arch directory.
If there's a problem, it's because the job is half done.
Remove support only if nobody is stuck without it and it's trivial for users to add if they do need it.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
As a native English speaker, those examples both make my ears bleed, so I think I agree with your point. Several doesn't just mean a specific range of numbers, but also that the speaker wants to convey that, in this context, that number is many or greater than expectation.
-Dave
It's in the second paragraph in the TFA ;)
I'd say you must be new here if you expect people to RTFA, but your UID is a respectable 4 digits...
"Don't meddle in the affairs of a patent dragon, for thou art tasty and good with ketchup." ~ohcrapitssteve
An x64 processor is expensive, large, and power-hungry for modern "pretty small systems." If you have far, far less than 4GB, you've probably moved to 32-bit ARM.
As others have answered, "several" in this context means a vague small number.
I'd like to point out that when writing up a news article, the author should have taken several minutes to look up exactly how long ago the X32 ABI was introduced.
"It was just six years ago..."
I'd say you must be new here if you expect people to RTFA, but your UID is a respectable 4 digits...
Or another way of putting it, his UID can be expressed in 11bits and is therefore obsolete and we should consider dropping support.
Obligatory xkcd
"Don't meddle in the affairs of a patent dragon, for thou art tasty and good with ketchup." ~ohcrapitssteve
Here's the LKML post that kicked it off, if you don't want to click through: https://lkml.org/lkml/2018/12/10/1145
I think his point #2 is probably the most "nutty", but that really does seem like an implementation detail:
x32 support removal is the kind of thing that should be thought long and hard about, because it's the kind of thing that will be nearly impossible to put back in once it's removed. Abstraction layers and edge cases keep us (and the kernel devs) honest, and have some value even if the number of users is small. Additionally, this seems like a classic case of chicken-and-egg with a lesser-used arch variation. Perhaps actual *publicity* after it was put in 6 years ago would have helped; perhaps this story itself will prompt more use.
Hire a Linux system administrator, systems engineer,
An x64 processor is expensive, large, and power-hungry for modern "pretty small systems." If you have far, far less than 4GB, you've probably moved to 32-bit ARM.
I admire your ideal world where management chooses components rationally.
Socialism: a lie told by totalitarians and believed by fools.
People under severe memory constraints who need to use pointers that take up only half the space? People under severe performance constraints who can't spare the cycles to copy 64-bit pointers or do 64-bit lookups?
As far as I know their support is feature complete, outside of bugs in the toolchain/kernel.
Personally all these 'lets delete xxx feature' discussions and removals is just making the linux kernel LESS interesting, while the major fuckups and bugs in the kernel are mostly in new, stupid, overengineered code that wasn't well thought out to begin with.
x32 from everything I hear has some shortcomings, but at the same time has been the proof of concept for all the other 32 on 64 bit ABI attempts made. Furthermore if they are fucking around with the syscall interface often enough for it to affect ABI compatibility, maybe they should be taking a hard look at their own development practices instead of those of other developers.
Ah damn ok it isn't x86, I was confused...
"Science will win because it works." - Stephen Hawking
You're right that this usage is weird. The other posters are correct about what number range the word "several" might represent, but they're ignoring its connotation. You're exactly correct that it has the sense of "more than expected".
"There are still several years left", or "This established feature has been there for several years" all make sense. "It was just several years ago" does not make sense.
Interesting thread/article here on /. today - refreshing & back to "old-school slashdot" imo (better than POLITICAL or "SJW" articles that have been hitting this place the past year or so now)... apk
Yeah, fewer and fewer real articles between the clickbait, but those few are still interesting.
Socialism: a lie told by totalitarians and believed by fools.
I tend to find that oddball intermediate layers like this die off rather quickly. In terms of "when I'd heard of it" to "when its death is proposed", this one is really quite quick.
I'm surprised that x86 is still supported, let alone an oddball "64-bit processor with 32-bit pointers" hybrid setup. Surely even x86 is only more for legacy and embedded chipsets, nowadays, where I can't imagine that x32 would help at all.
Either your chip is 64-bit capable, or not. If it is, even if there are minor advantages to running it in 32-bit mode, when there is COMPLETE and total support for 64-bit mode, it seems a nonsense not to use it. If it's not, then the question is moot anyway.
It's not like ARM or Intel of old where all the previous chips used 32-bit, then they supported 64-bit but people didn't get on board with it for a while. It's people with full-64-bit support, that can run either full 64-bit or full 32-bit, but choose to use an oddball and barely-supported middle ground because... well.. they don't want to use 64-bit pointers and use a little more memory.
It's like running your 80386 in 8086 mode. It may have been useful for a short period of time in the transition when the new hardware was expensive but the old software was more expensive to replace, but it'll die off and you'll never use it again. Except, in this case, it's wanting to use the 80386 chip features in a machine, but in such a way that it can only address 1Mb of RAM. Not even "use the 80386 as an 8086" but literally "I want to use the extra processor registers but not the full 4Gb of RAM, just the first Mb".
And in an era where 64-bit hardware has been the norm for nearly 2 decades now.
Don't take the 10% advance away from me! :-/ https://t2sde.org/
Whether Al Gore is a conman or not has absolutely no effect on whether humans are causing global warming. Your argument is that the warming over the past few decades is due to natural variability, though you haven't a clue what kind of natural variability you're implicating. I explained the physical processes by which human activity is causing the Earth to warm. Rather than discuss the science, you replied with personal attacks and mostly copied and pasted your previous idiotic post. Most likely, you don't know a thing about how the climate system works, so personal attacks and mindless rhetoric are your tools of choice.
Just so you know, I'm a meteorologist. My field is closely related to climatology, and I have a good understanding of how the climate system works. I've actually run climate and weather models. I've presented my work at professional conferences and published in peer-reviewed journals. I've run numerical weather prediction models like WRF and CM1 on hundreds of cores to simulate processes in the atmosphere. Much of what I do focuses on processes within thunderstorms but I certainly do understand the climate system and have done a portion of my work in that area.
Since you don't provide any scientific arguments that can be discussed, what are your qualifications that merit trusting you about climate change? Please do tell.
Again, you are complaining about users modding you down. This certainly qualifies as complaining:
REPOSTED 2nd time to exhaust the LIMITED abused DOWNMODPOINT of an obviously OBSESSED psychotic LOON that STALKS me constantly & downmods me projecting his MENTAL issues here https://linux.slashdot.org/com... off topic.
Again, that is you complaining. By "take EFFECTIVE ACTION", you mean that you spam your posts that were previously modded down. You've admitted to that multiple times in this story.
It is logical that lots of users, almost certainly a large majority of readers, consider your posts to be of poor quality. That is why you are consistently modded to -1, and why numerous users have asked Slashdot for years to curtail your spam. You are simply incorrect when you say this is the work of a single "mental loon" because many more users would have to agree your posts are of low quality.
Why are you so obsessed with how your posts are moderated? That would not seem to be healthy. You've turned to posting cconspiracy theories that this is one user out to get you. You've recently started posting again about your obsession with whipslash and how you're still upset after two years that he modified the lameness filter to limit some of your spam.
Seek professional help.
So, yes, human activity is driving the warming over the past few decades. Insult me if you must, but that won't change the physics involved.
You gave a nice middle-school level Earth Science description of how global warming works, but you gave no evidence for this claim. Obviously, human activity affects the climate, the question is: just how much, exactly?
If you look a bit deeper into the science you'll find it's all about feedback loops. The amount of CO2 in our atmosphere wouldn't amount to much warming without positive feedback loops. There are also negative feedback loops, and it's all poorly understood, which is while climate science is an actual science where original work is happening. If it were all so clear, it wouldn't be a field of study.
Just to start: almost all of the greenhouse* effect comes from water vapor. The atmosphere is effectively saturated, so the key is how much water can the air hold at a given temperature. Warmer air holds more water, so positive feedback. But wait, more clouds increases the Earth's albedo, so negative feedback. This also is why no climate (or weather) model is meaningful without modeling the oceans (ocean temps matter a heck of a lot).
*"Greenhouse" effect is a stupid name. Greenhouses work by letting in light and blocking convective losses (and limiting conductive too, in anything modern). Glass trapping outgoing IR barely matters.
Socialism: a lie told by totalitarians and believed by fools.
We're only talking about dropping support for referencing UID 1135 directly. He can still reference it like everyone else by using the standard UID 0000001135 scheme.
People under severe memory constraints who need to use pointers that take up only half the space? People under severe performance constraints who can't spare the cycles to copy 64-bit pointers or do 64-bit lookups?
Why are said people using a 64-bit CPU in the first place, then? Let them use a 32-bit ARM CPU or something, and stop gimping the x86_64 architecture.
Because the architecture offers significant enhancements besides 64-bit pointers, and they want those enhancements without having 64-bit pointers for the reasons I stated.
Hey Ivan, welcome back!
For today's English lesson, go and look up Ms. and Miss.
Stop complaining about the summary when you don't even understand basic English. Try running it through Google Translate or something.
Modern memory-constrained systems are not x64, though. They're ARM. The type of memory constraints that x86 systems have are not at the scale that benefits from accessing half a register.
And when you're programming an embedded system that is that memory-constrained, it is perfectly normal to have sections of inline ASM. So that is what you'd do if you actually needed this.
And generally when things are that constrained you're not using linux anyways. That's the real point. People accessing half a register are running Mbed OS or FreeRTOS or something. Before you want this feature, you already switched to ARM, and you probably also then went smaller than linux.
I'm an embedded dev, and this is totally useful on any platform with 4G of memory, which is a lot of them. It is, in fact, probably the most optimal way to run an x86_64 processors on a platform that actually does not need more than 32 bits of address space. This is a non-trivial number of applications. Like, lots. There are computers beyond servers and engineering workstations ya know. Lots more. You just conveniently pretend embedded and/or purpose-built systems are designed and programmed by magic.
Just because the BOFH didn't explain their reasons, doesn't mean they were irrational. It only means you're not important enough to know. And the BOFH is probably an engineer.
This should only save space, not cycles. A 64 bit computer takes the same time to do a 64 bit or 32 bit operation. This is all about pointer size.
The same thing exists on 32 bit machines, where it is normal to support both 32 and 16 bit pointers.
I am still hoping for 8-bit support one day for the M6809 processor... Dang.
Honestly -- I don't know why there ever was so much movement toward x64 -- everything takes more memory..
Provided ... you do not use the C programming language.
Java has done this for a long time. Pointers only point to things that are 8 byte aligned. And you do not do pointer arithmetic just to parse a String.
Regarding the responsibility for the recent warming, I'll offer two hypotheses: man-made greenhouse gases and changes in solar output. If the solar output is the main factor, we would expect to see solar output increase to coincide with the warming. In reality, it's remained steady, if not slightly decreasing. However, the greenhouse gases concentrations continue to increase, and do a better job of explaining the observed warming.
You're familiar with the ice core data from Vostok et al? The clockwork regularity of the 100k year cycle is clearly solar. And yet, 10k years ago the clock broke, and the glaciers did not return. Why not? No one knows, but solar output remaining steady is a glaring anomaly.
The past 10k years of relative climate stability are unique in the past million-ish years that we have data for. Good thing too, as it's what allowed humans to become technological.
To me, the biggest question is where would the climate be heading without human activity. Solar models are even more primitive than climate models, so no one has a clue, but it's the most important question. Glaciers are a far worse threat than warming, at least to us humans, but they're already 10k years overdue, and just maybe the Quaternary Ice Age is ending, and it's going to get a lot warmer.
Socialism: a lie told by totalitarians and believed by fools.
Its nice to see an informative post by a dedicated Slashdot fan (a rare action now a days). I ran out of mod points but I thing I would friend you instead. Thanks Misagon.