Hacker News Reader

Comment by RetroTechie | Hacker News Reader

Reads like a typical "will be released when it's ready, but it's not ready".

Or providing a (single) generic kernel for RISC-V is impractical, so support for that is removed until another approach is figured out? Just speculating here.

But Android-on-RISC-V is pretty much unavoidable at this point. Google-blessed or otherwise. If Google won't do it (article does not suggest that?), the open source community will. Or the Chinese. Or some other deep-pocketed corp interested in pushing this ahead.

View on HN

The question is, which RISC-V? You're providing a single kernel for phone-like things, so probably RV64I as a base. MAFD is pretty much required for running a Java VM. Q, no. C, are you shipping for Si-Five or Qualcomm? J/T/P/V would be useful, but does the kernel need it? H is needed for Android phones these days but not watches. S, no idea.

The explanation makes sense to me; let the dust settle and have real hardware shipping before defining the base feature set in a generic kernel image.

The sheer number of RISC-V extensions and the resulting fragmentation is blowing my mind. No wonder they can't provide a single generic kernel.

There are baseline profiles, like RV23A, that standardize a set of extensions for a class of hardware. Problem right now is that Qualcomm and Si-Five disagree on what extensions should be supported, and there is hardware shipping or in development with two different definitions.

Literally everybody agrees except Qualcomm who want to basically no participate, come in on the side and make it quasi propitiatory.

Couldn't Google (who after all does Android) simply declare that the 'official' RV64 is IMAFD (aka 'G') CJQTVPBHLNSUX ? (or whatever makes sense, given the android roadmap). https://en.wikichip.org/wiki/risc-v/standard_extensions

And if they did this, this would prove why Android's parent company is called Alphabet!

There is a standard profile called 'RVA22' and 'RVA23' after that. If you watch the presentations from google on this, they will almost certainty target one of those two standards, very likely RVA23, specially if its now delayed.

Android could also define its own profile, but there probably wont be a reason for why they would need to do this.

It's really not that bad when you consider that RISC-V is built to be used in anything from a tiny mcu to a large server cpu. Compare with the set of extensions to x64, too.

It hasn't actually resulted in that much fragmentation. Android will target the standard profile, they have already announced that. There are standard profiles that pretty much get used by everybody that is trying to make something that runs generic software.

If you have some one of consumer electronic device that runs one specific software, you might not follow a profile, but even then most will follow a specific profile.

What's MAFD?

(I don't know the instruction-set well and Google didn't turn up anything informative.)

https://en.wikipedia.org/wiki/RISC-V#ISA_base_and_extensions

That doesn't directly answer the question.

The answer seems to be that MAFD refers to the union of the M, A, F, and D extensions to the baseline ISA, adding integer multiplication and division instructions (M), atomic instructions (A), single-precision floating point instructions (F), and double-precision floating point instructions (D).

Does it? They say the risc-v support “is discontinued”, which seems to imply something much stronger than what you say.

The article says:

> Android will continue to support RISC-V. Due to the rapid rate of iteration, we are not ready to provide a single supported image for all vendors. This particular series of patches removes RISC-V support from the Android Generic Kernel Image (GKI).

There is some more context in the android SIG: https://lists.riscv.org/g/sig-android/topic/105816077#msg389

that link makes it much more clear

  > they are removing older code for Qualcomm specific use case that is no longer supported (Wear OS IIRC was discontinued). That pre-dates all the current work, so I expect this was removed because the platform was deprecated

and

  > since maintenance of an officially _labelled_ GKI kernel is more expensive, we're removing the sticker for now.

so... basically a nothingburger?

> But Android-on-RISC-V is pretty much unavoidable at this point.

I’m curious to know what happens to the significant portion of apps that rely on the NDK? Might there be some possible emulation layer like Rosetta 2 like with Apple Silicon?

If Google cares enough, then yeah probably. They have an emulator (libhoudini) to run ARM apps on x86 (Chrome OS being the main use case)

Reply on news.ycombinator.com