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