Hacker News Reader

Comment by rwmj | Hacker News Reader

There's nothing that's compatible with RVA23 except qemu, and very few boards which are even partially compatible. Ubuntu's decision is a dumb one. This should run Fedora or Debian just fine.

View on HN

> Ubuntu's decision is a dumb one. This should run Fedora or Debian just fine.

You either pull the future forward, or drag the past. Because of the small market, they decided to forgo generating legacy concerns before they even started seeing mainstream adoption.

I like the decision (they are choosing a better foundation) but I can see the merits either way.

It's fine to be forward looking, but if you're so forward looking that you literally support zero hardware on the market, you might have gone too far.

They should have two streams. For Fedora we've got Fedora vs CentOS Stream, with the latter (going to be) tuned more for RVA23 and server boards.

I don’t think it’s dumb - hasty and premature perhaps. Manufacturers have been shipping boards with flaky RVV support, a years old kernel and undocumented blobs on in house baked OS and calling it a day.

Feels like a step towards strong arming them into shipping products that can be supported easier/not being left to rot in a drawer.

A lot of people would call a hasty, premature decision "dumb". I generally would, at least.

For release 26.04 next year, it makes more sense because that is a Long Term Support release and a lot of new hardware from then on will be RVA23-compliant.

They recommend 24.04.3 LTS for current hardware. Maybe they just don't want (then) old hardware to be stuck on a non-LTS release.

Ubuntus decision was the right one, RVA23 is the first ‘full’ desktop class isa for riscv

Ubuntu is specifically a noob friendly desktop OS. No reason for them to bother supporting slow buggy embedded CPUs.

A person might suggest that it would be more user friendly to support hardware that people own. There's a parallel to years ago, when Ubuntu was a lot like Debian but it was willing to ship non-free firmware by default because that was the hardware that people actually had, which is part of why it was praised as noob friendly.

I don't think it's dumb. There are very strong hints that we can expect SpacemiT K3 RVA23 boards from possibly multiple vendors by perhaps the end of the year and certainly not long after that.

Leaving RVA23 support until 28.04 LTS would be FAR too long.

It would be nice to see both RVA20 and RVA23 supported in the same OS but the problem is that it's not actually practical to do runtime selection of alternative functions or libraries for all extensions in RVA23. It is possible and sensible for things such as V, perhaps, but extensions such as Zba and Zbb (not in RVA20, but supported by VisionFive 2) and Zicond, Zimop, Zcmop, Zcb have instructions which want to be sprinkled all through just about every function.

You'd have to either deny your main program code the use of all those extensions, or else completely duplicate every program binary.

Performance aside, is it feasible for those extensions to trap and emulate in the kernel? Like old ARM Softfloat or linux/arch/x86/math-emu ?

Sure of course, but that's going to cost something like 500 cycles [1] to emulate something that only exists to save 2 or 3 cycles.

Also, not in the kernel but in SBI -- in Machine mode not Supervisor mode.

[1] estimate based on how long it takes to trap and emulate misaligned accesses on VisionFive 2.

Is RISC-V the IPv6 of processors?

Reply on news.ycombinator.com