Linus Torvalds Lashes Out At RISC-V Big Endian Plans

submitted by

https://www.phoronix.com/news/Torvalds-No-RISC-V-BE

Linus Torvalds has come out strong against proposed support for RISC-V big endian capabilities within the Linux kernel.

In response to a mailing list comment whether RISC-V big endian "BE" patches being worked on would be able to make it for this current Linux kernel cycle. Linus Torvalds initially wrote:

"Oh Christ. Is somebody seriously working on BE support in 2025?

WHY?

Seriously, that sounds like just stupid. Is there some actual real reason for this, or is it more of the "RISC-V is used in academic design classes and so people just want to do endianness for academic reasons"?

Because I'd be more than happy to just draw a line in the sand and say "New endianness problems are somebody ELSES problem", and tell people to stop being silly.

Let's not complicate things for no good reason. And there is NO reason to add new endianness.

RISC-V is enough of a mess with the millions of silly configuration issues already. Don't make it even worse.

Tell people to just talk to their therapists instead. That's much more productive."

22
145
2

Log in to comment

Hot Top New Old
edited

He's right. I think it was really a mistake for RISC-V to support it at all, and any RISC-V CPU that implements it is badly designed.

This is the kind of silly stuff that just makes RISC-V look bad.

Couldn't agree more. RISC-V even allows configurable endianness (bi-endian). You can have Machine mode little endian, supervisor mode big endian, and user mode little endian, and you can change that at any time. Software can flip its endianness on the fly. And don't forget that instruction fetch ignores this and is always little endian.

Btw the ISA manual did originally have a justification for having big endian but it seem to have been removed:

We originally chose little-endian byte ordering for the RISC-V memory system
because little-endian systems are currently dominant commercially (all
x86 systems; iOS, Android, and Windows for ARM). A minor point is
that we have also found little-endian memory systems to be more
natural for hardware designers. However, certain application areas,
such as IP networking, operate on big-endian data structures, and
certain legacy code bases have been built assuming big-endian
processors, so we have defined big-endian and bi-endian variants of RISC-V.

This is a really bad justification. The cost of defining an optional big/bi-endian mode is not zero, even if nobody ever implements it (as far as I know they haven't). It's extra work in the specification (how does this interact with big endian?) in verification (does your model support big endian?) etc.

Linux should absolutely not implement this.

 reply
60

I guess that could be useful if you're designing a router OS? Is that even going to be a significant benefit there?

 reply
3

Unlikely, you'd do packet processing in hardware, either through some kind of peripheral or if you're using RISC-V you could add custom instructions.

 reply
10

I agree with him tbh. There is no reason for endianness except we used to not agree on a single one. And as far as I'm aware, pretty much everything is LE at this point (when it comes to processor architecture)

 reply
33

As someone who only ever heard others argue about it, this sounds like something out of the 90s to me.

Weird stuff.

 reply
7

Mmmmm I don't understand any of that lol

The mainline kernel is for mainline development. Not for random experiments that make the world a worse place.

And yes, we're open source, and that very much means that anybody is more than welcome to try to prove me wrong.

If it turns out that BE RISC-V becomes a real thing that is relevant and actually finds a place in the RISC-V ecosystem, then of_course we should support it at that point in the mainline kernel.

But I really do think that it actually makes RISC-V only worse, and that we should not actively help the fragmentation."

I was worried this meant he was voicing disapproval for RISC-V in general, but he's actually just taking about an implementation or maybe particular part instruction set or something?

I'd be curious how other RISC-V knowledgeable folks feel, whether they agree or disagree

 reply
13

Big endian is a byte order scheme. For registers and memory. If I'm not mistaken, pretty much all modern systems these days are little endian. The differences can largely be mitigated at the operating system level. But it definitely invites new chaos back into the equation. If programs don't get their bytes in the right order, it will be garbage in garbage out everywhere. Try playing an old PCM wave file from a 68k based Macintosh or Amiga on a PC.

 reply
28
edited

Try playing an old PCM wave file from a 68k based Macintosh or Amiga on a PC.

I really appreciate how specific this is. It sounds like it’s from experience.

 reply
14
edited

It 100% is. I have distinct memories back in the 80s of getting a hold of files off of FidoNet, etc. and trying to play them only to find out they were big endian files. It sounded like a mildly uncomfortable shoggoth in a blender. It had nothing on the dulcet tones of dial up modems.

 reply
17

The differences can largely be mitigated at the operating system level.

Exactly. And that also means that they have to be mitigated at the OS level and in this case, the kernel level.
It would usually be fine if the system had nothing other than RAM and fixed storage, but anything else (as simple as keyboard drivers and stuff) and you will need to make the program accordingly. Maybe even SATA would require handling endianness.

Honestly, I thought that they already handled endianness, due to how many different things Linux works on.
But if it doesn't then I don't see there being much of a requirement.

For networking devices and such, I'd rather favour more customised solutions either way.

 reply
3

Interesting, thank you for explaining what it is!

 reply
2

@Eldritch
I don‘t think the order of the bits and bytes in some file format depends on the byte order inside cpu registers.

 reply
-1

Some formats are designed around a particular endian-ness. But not all. Some only specify where a byte is to be stored and what it should represent. But not how it should be stored. PCM WAV files are ancient and uncompressed. with a few bytes in the headder telling you bit depth and sample rate. Followed by a stream of raw bytes representing the samples. Whether you store those bytes in LSB or MSB order. They're both valid. But passing such a file to a system expecting the opposite. Your file will still play. It will just be squealing noise.

Bitmap images can be similar as well. So arbitrary is the data in RAW Bitmap files. That you can open it in audio software like Audacity as a raw PCM. Perform Fourier transforms or other audio options on it. Save the raw byte stream back out as an image again. Bytes are bytes, and a lot of formats don't care what order they're in. Even if the user might.

 reply
5

If you have a file containing 4 bytes, where the first byte in the file is 0x01, second is 0x02, third is 0x03, and 4th is 0x04, and you keep that same order when you load them into the first 4 bytes of memory on an LE machine vs a BE machine, what value does the uint32 located at address 0 contain? On LE it's 0x04030201, on BE it's 0x01020304. So yes, it absolutely matters.

 reply
5

Not on RISC-V. The registers don't really have an endianness. They're just bit vectors - you can't address within them.

When you access memory the current endianness setting determines the mapping between the register value and the bytes in memory. It's the access that has endianness; not the register.

 reply
1

There aren't currently any RISC-V hardware implementations that support big endian (although I guess someone must have tried it on a simulator), so supporting it in the Linux kernel is about as useful as supporting any other hypothetical CPU that only exists on paper. The mainline kernel is meant for computers that exist in the real world, so supporting BE RISC-V should only happen after such CPUs have actually been made. As things stand, there's nothing to suggest that anyone will bother making them, so the Linux maintainers shouldn't bother supporting them.

 reply
10

I really appreciate the accessible explanation, thank you!

 reply
2

Tell people to just talk to their therapists instead. That’s much more productive.

I'm just going to say it: 50% of foss projects wouldn't exist if their devs could afford therapy

 reply
6

Why does this Linus Torvalds person care how I eat my eggs?

 reply
5

IDK, maybe he is washing the plates or sth?

 reply
4

At least his own therapist has helped him express himself only a little unprofessionally.

 reply
-9

Comments in RISC-V@programming.dev

Torvalds has never been known for not speaking his mind,. But in this instance I'm not sure I would disagree with him. This isn't the 70s, 80s, or even the 90s at this point. Things largely have settled on little endian.

I'm going to assume that if people are still trying to push big endian. There must be some point to it or some advantage. Though I have no idea what it would be.

 reply
9

Um, stop holding back, Linus.

 reply
3

This attitude is exactly why I try to stay away from Linux. Bring on the downvotes, I don't care.

I refuse to separate the art from the artist, which is what boycotting in general really is IMO.

It's like being gifted a haunted house. Technically the house is structurally sound, the design of the house itself is not a problem... but even just being outside around the house makes me feel uneasy. I don't like what happens on the inside OR the outside, and I just prefer to stay away from it.

 reply
-6

To each his own.

Personally, I would want to live in a house where someone loudly reacts to somebody suggesting to remove a load-bearing wall for cosmetic reasons. I do not want them to pretend that it is a reasonable suggestion. Speak plainly!

 reply
3
edited

I think it is very possible to speak plainly and even rather assertively without actually devolving into personal attacks and abusive tones, and I don't think it's too much to ask. I would even suggest that it would be better for everyone if we could all just be a little bit nicer.

Example from Linus:

This code is GARBAGE.

A better way to get the same point across:

This code does not make any sense to me.

 reply
1

it would be better for everyone if we could all be a little bit nicer

I agree with that

personal attacks

I agree, personal attacks are bad

“this code does not make any sense to me”

But here is the problem. Your two versions are not the same. The problem is not that Linus does not understand the code. The issue is that he does.

I believe strongly that high performance culture requires that it be absolutely ok to talk about the quality of an idea or about the work and that this NOT be seen as attacking the person.

“You are an idiot” is not ok. “This code is garbage” has to be (at least from the guy whose job it is to determine code quality). You can say “this code is very low quality” or “this code is totally unacceptable” if you like.

Co-pilots will allow pilots crash planes out of respect. Engineers allow bad designs to crash planes too. Neither of these are preferable to speaking openly and plainly, at least not in my view.

Lives absolutely depend on the Linux kernel. It is ridiculous to say they do not. What do we value more, comfort or safety?

Please be nice. Please also say exactly what you mean. At work at least. Suffering fools gladly is a better strategy at play and at home.

 reply
3
edited

The problem is not that Linus does not understand the code

I think it depends on the definition of "understand" in this context. In my example I used the words "does not make sense", but I did not quantify what that meant.

It could be interpreted as making sense in the context of doing things in a way that's acceptable to him.

If that doesn't "make sense" to you either, feel free to insert whatever other wording gets your point across, but I think you understand what I'm trying to say, which is that I think there is still room to be much nicer than Linus currently is, without losing the intended effect, but at the same time also not angering near as many people for (IMO) unnecessary reasons.

 reply
1

Difference is, you don't get to read the kind of letters Pavan Davuluri writes to his teams.

 reply
3
Insert image