Um, stop holding back, Linus.

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.

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.

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)

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

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

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