136
How is RISC-V better than arm for Linux?
(programming.dev)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 06 Aug 2024
136 points (97.2% liked)
Linux
48074 readers
783 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
RISC-V is better for Linux due to driver support. Vendors making hardware are more likely to use RISK-V for their controllers due to the costs. Modern computers are putting more functions under control of kernels that run on proprietary compute. (There exists a chart showing how little the Linux kernel directly controls.) As more of those devices run RISC-V, they will become more discoverable.
Also, those that can design or program tge devices will have more transferrable skills. Leading to the best designs spreading, and all designs improving.
Places in a computer with compute (non-exhaustive, not all candidates for RISC-V):
BMC
Soundcard (or subsystem on mainboard)
Video card (GPU and the controller for the GPU)
Storage drives
Networking
Drive interface controlling card
Mainboard (not BMC)
Keyboard
Mouse
Monitor
UPS
Printer
Will it be perfect? Nope.
A lot of the vendors will lock things up as well.
I'd be greatly interested in seeing this chart
USENIX ATC '21/OSDI '21 Joint Keynote Address-It's Time for Operating Systems to Rediscover Hardware
Timothy Roscoe, ETH Zurich
https://youtu.be/36myc8wQhLo
At 19:22
examples he gives are what you'd expect:
Many systems on the chip that Linux doesn't have control over, and could be compromised by a cross SoC attack
Thank you for pulling the image out.
This talk surprised me at the time. I was starting the eye opening experience of design hardware. Linux more orchestrates the hardware than controlling it.
For me it opened my eyes to the idea that all you really need is some CPU time and a little RAM space to have a full-fledged performative system. Sure, there will be a large attack vector for remote spying, but if you just want to code and play games then it's pretty amazing how little you need :-)
Same here
To avoid convo in multiple places, it is in reply to message you replied to.
Thanks!
There's also the fact that Arm doesn't really work with arbitrary PC style hardware. Unless this got fixed (and there have been some pushes) you have to pretty much hard code the device configuration so you can't just (for example) pull a failed graphics card and swap a new one and expect the computer to boot. This isn't a problem for phone (or to an extent: laptop) makers because they're happy to hard code that info. For a desktop, though, there's a different expectation.
RiscV does support this, i believe, so in that sense it fits the PC model better.
I don’t follow. Isn’t the OS’s job to discover hardware? How is the CPU instruction architecture come into play here?
See the start of this post talking about device tree models vs boot time hardware discovery.
There's no reason an arm chip/device couldn't support hardware discovery, but by and large they don't for a variety of reasons that can mostly be boiled down to "they don't want to". There's nothing about RISC-V that makes it intrinsically more suited to "PC style" hardware detection but the fact that it's open hardware (instead of Apple and Qualcomm's extremely locked down proprietary nonsense) means it'll probably happen a lot sooner.
Thank you, that was very elucidating.