arch/riscv/staging
Paolo Bonzini
pbonzini at redhat.com
Fri May 28 04:28:16 PDT 2021
On 28/05/21 12:59, Greg Kroah-Hartman wrote:
> On Fri, May 28, 2021 at 11:37:02AM +0200, Paolo Bonzini wrote:
>> On 28/05/21 11:24, Greg Kroah-Hartman wrote:
>>> Ok, as it sounds like this isn't going anywhere until the spec group
>>> gets their work done, you all should just wait as there's no real need
>>> for any kernel code here either, given that there can't be any hardware
>>> made until the spec is finished anyway.
>>
>> There's need for kernel code so that userspace tooling can be built upon it.
>> Not having the header files in Linus's tree makes it harder to merge RISC-V
>> KVM support in userspace. KVM shields userspace from any future changes to
>> the hypervisor specification; the userspace API *is* based exclusively on
>> ratified specifications and there's no risk of breaking the ABI.
>
> The "risk" is the kernel/hardware api, that seems to not be solid yet
> given the spec is not released so I understand why the riscv maintainers
> do not want to accept it.
The key word is "seems". We _have_ worked on making the spec solid; no
one that has actually done work on hypervisors for RISC-V believes that
it is not solid. No work has been done on the spec for one year
*because there's no work to be done*.
So the people who actually do the work are twiddling thumbs and waiting
for the freezing of all the dependent specs (of which there's a new one
every time I check, because the goalposts for freezing the spec keep on
being moved). And at this point probably waiting for hell to freeze as
well.
Anyway---I understand that you don't care (you shouldn't). Just from my
point of view it's ridiculous that I cannot merge code that is
completely standalone just because it has one file in
arch/riscv/include/asm/uapi, and that RISC-V maintainers cannot
participate in the community the same way everyone else does.
Paolo
More information about the linux-riscv
mailing list